From nobody Sun Mar 2 23:27:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0101A0D4E for ; Sun, 2 Mar 2014 23:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.146 X-Spam-Level: X-Spam-Status: No, score=-3.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 2WNmaE5KJ8hX for ; Sun, 2 Mar 2014 23:27:14 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B57241A03E5 for ; Sun, 2 Mar 2014 23:27:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAGotFFOHCzIm/2dsb2JhbABagkIjITtXwE+BGxZ0gicBAQMSG14BFRVWJgEEGxqHVwGcRYRUqyyOKINcgRQEny6DcYdIgy2CKg X-IronPort-AV: E=Sophos; i="4.97,576,1389762000"; d="scan'208,217"; a="44896363" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Mar 2014 02:27:09 -0500 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; 03 Mar 2014 02:13:50 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 3 Mar 2014 02:27:07 -0500 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: more important information for the WG meeting this week Thread-Index: Ac82sfr2l68wv4t6Rw2fnPQTJJmUVQ== Date: Mon, 3 Mar 2014 07:27:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E43F3B2@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E43F3B2AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WcRMvD96qjxTCX9_Y2UF2a9ghx4 Subject: [lmap] more important information for the WG meeting this week 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, 03 Mar 2014 07:27:19 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43F3B2AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, To make the best of the meeting time this week please: - Read the agenda and the documents in the reading list and come p= repared for constructive comments and discussions about the documents on th= e agenda - If you own an item on the agenda please send us your presentatio= n until the evening before the meeting - Volunteer to be a scribe for the minutes and jabber - from our e= xperience short notes from several people are better - If the time will allow we will discuss new items and ideas at th= e end of the meeting but only if all WG items on the agenda were discussed Thanks and Regards, Jason and Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA2E43F3B2AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

To make the best of the meeting time this week pleas= e:

-     &= nbsp;    Read the agenda and the do= cuments in the reading list and come prepared for constructive comments and= discussions about the documents on the agenda

-     &= nbsp;    If you own an item on the = agenda please send us your presentation until the evening before the meetin= g

-     &= nbsp;    Volunteer to be a scribe f= or the minutes and jabber – from our experience short notes from seve= ral  people are better

-     &= nbsp;    If the time will allow we = will discuss new items and ideas at the end of the meeting but only if all = WG items on the agenda were discussed

 

Thanks and Regards,

 

Jason and Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA2E43F3B2AZFFEXMB04globa_-- From nobody Tue Mar 4 04:05:36 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5A1A075F for ; Tue, 4 Mar 2014 04:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.442 X-Spam-Level: X-Spam-Status: No, score=0.442 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] 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 RLQ1mAHojr8F for ; Tue, 4 Mar 2014 04:05:32 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB0F1A075E for ; Tue, 4 Mar 2014 04:05:32 -0800 (PST) Received: from ([24.40.56.122]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.119522306; Tue, 04 Mar 2014 05:05:27 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.171]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 07:05:49 -0500 From: "Livingood, Jason" To: "lmap@ietf.org" Thread-Topic: Network World: A call for open standards for broadband performance testing Thread-Index: AQHPN6JH6s4GDpAuyU+HdHzDklmQyw== Date: Tue, 4 Mar 2014 12:05:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.247] Content-Type: multipart/alternative; boundary="_000_CF3B7202C6B46jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/pqYEL0swciefozw_stN_Ar7Zbqo Subject: [lmap] Network World: A call for open standards for broadband performance testing 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, 04 Mar 2014 12:05:35 -0000 --_000_CF3B7202C6B46jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable May be of interest to us here: http://www.networkworld.com/news/2014/021814-broadband-performance-278832.h= tml?page=3D1 News A call for open standards for broadband performance testing One expert thinks broadband testing should open up for better collaboration= . By Colin Neagle, Network Wor= ld February 18, 2014 08:35 AM ET * Add a comment * Print inShare Network World - With AT&T announcing its sponsored data initiative, a federal appeals court ruling that the FCC can no= longer protect net neutrality, and Comcast announcing a $45 billion acquis= ition of Time Warner Cable, business and consumers alike need accurate info= rmation on broadband performance more than ever. Data is the one tool that customers have to identify when ISPs might be imp= eding performance based on business disputes with content providers. For example, an article published at Gigaom earlier this month cites data provided by Measuremen= t Lab (called M-Lab for short), a consortium formed in 2009 by Google, the = Open Technology Institute, PlanetLab Consortium, and academic researchers f= rom across the country that contributes to the FCC=92s annual Measuring Bro= adband America report. The data referenced in the Gigaom article shows a steep decline in throughput = speeds for Comcast, Time Warner Cable, and AT&T from early 2013 through Dec= ember. By comparison, three other ISPs =96 Cox Communications, Cablevision = Systems, and Charter Communications =96 showed no decline over the same per= iod. However, M-Lab=92s data doesn=92t quite square with that from other broadba= nd testing services. The Gigaom article claims a source confirmed that SamK= nows, a company that provides routers to consumers that track broadband spe= eds and whose data also contributes to the FCC=92s report, was not spotting= the same trends. The same goes for Ookla, the company behind the popular S= peedtest.net website. Thomas Gideon, the technology director at the Open Technology Institute, ad= dresses these kinds of discrepancies between different broadband tests by p= ointing to M-Lab=92s broad testing method and its overall openness. M-Lab= =92s network diagnostic test utilizes the Web 100 instrumentation package, = and it generates roughly a half a terabyte per day, Gideon says. This data = is collected from 12 different experiments run on networks that were volunt= eered for testing. All the raw data is open for review so others in the ind= ustry can contribute. =93All of this openness is so that, like with a drug trial with any kind of= exploratory research, somebody else can take all of those inputs and ask g= ood, insightful questions about our results, can advance that working colla= boration, can use that data to try to see what insights it might provide on= other aspects of the network that are measured by the NDT tool,=94 Gideon = says. As for the differences between M-Lab=92s data and that of other providers, = Gideon says its tests capture a broad set of data from a point that reflect= s end users=92 network experience. =93We=92re looking at the total state of the network as we find it, and loo= king for those organic findings as well, so we have our servers situated wh= ere they are so they=92re very similar to the source=92s choice that a cont= ent delivery network makes in terms of setting up its caching infrastructur= e or a content provider might make,=94 Gideon says. =93So it=92s a little c= loser to the sorts of paths that are likely to be involved when you=92re de= aling with this question of customer experience.=94 M-Lab=92s open standards don=92t necessarily make it more accurate than oth= er tests, however. =93I don=92t think it=92s a question of accuracy, I think it=92s a question= of what insights specifically are you looking to glean,=94 Gideon says. = =93If you=92re looking to ask very narrow questions then you=92re going to = get very narrow answers.=94 What would make broadband performance data more accurate, and simultaneousl= y resolve the discrepancies between different tests, would be openness amon= g all organizations that perform these tests, Gideon says. The Open Technol= ogy Institute has worked with the FCC and others in the space to try to pro= mote open standards for broadband testing. Opening up the data is the only = way to figure out why two tests of the same network may show different resu= lts, Gideon says. =93You do it this way, you share your findings and your data and methodolog= y, in the way that you do so that other people can reproduce it, they can v= alidate your results,=94 he says. =93And they can also, in a case where thi= ngs don=92t quite line up, where there may be subsequent questions, they ca= n collaborate and cooperate with you to improve over time so that you=92re = getting better and better results, you=92re getting keener insights, you=92= re just getting a better picture of what=92s going on.=94 Gideon says SamKnows is very cooperative with its open policies, which M-La= b requires as a condition when it collaborates with other organizations. As= for other companies that test broadband, he says M-Lab is always open to d= iscussing partnerships that could go into deeper detail on performance tren= ds. However, direct collaboration wouldn=92t be as important if the FCC were to= establish standards for broadband testing, which Gideon says has become in= creasingly possible over the past few years. Crediting the FCC for bringing= together the public interest, the federal government, and the private sect= or to establish a =93good comparative basis across technologies,=94 Gideon = says standards for broadband testing may not be that far away. =93I think there are plenty of actors, including the FCC, working on standa= rds efforts, there=92s a lot of stuff in flight,=94 Gideon says. =93I would= n=92t presume to say that it=92s all the way there yet, but I would definit= ely like to see from our perspective more open standards around these sorts= of things, because I think it invites more people into the field from all = across the space: from private sector, from academia, from public interest.= And it puts us on that same footing that that we=92d like to be on in term= s of open and comparable methodologies, open and comparable tools.=94 Colin Neagle covers emerging technologies and the startup scene for Network= World. Follow him on Twitter @ntwrkwrldneagle and keep up with the Microso= ft, Cisco and Open Source community blogs. Colin's email address is cneagle= @nww.com. --_000_CF3B7202C6B46jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
May be of interest to us here:


News

A call for open standards for broadband performance testing

One expert thinks broadband testing should open up for better collaboration= .

By Colin Neag= le, Network World 
February 18, 2014 08:35 AM ET

Network= World - With AT&T announcing its sponsored data initiative, a federal appeals court ruling that the FCC can no lo= nger protect net neutrality, and Comcast announcing a $45 billion acquisiti= on of Time Warner Cable, business and consumers alike need accurate informa= tion on broadband performance more than ever.

Data is the one tool that customers have to identify when ISPs might be imp= eding performance based on business disputes with content providers.

For example, an article published at Gigaom earlier this month cites data provided by Measurement Lab (called M-Lab for short), a consort= ium formed in 2009 by Google, the Open Technology Institute, PlanetLab Cons= ortium, and academic researchers from across the country that contributes t= o the FCC=92s annual Measuring Broadband America report. The data referenced in the Gigaom article shows a steep decline in through= put speeds for Comcast, Time Warner Cable, and AT&T from early 2013 thr= ough December. By comparison, three other ISPs =96 Cox Communications, Cabl= evision Systems, and Charter Communications =96 showed no decline over the same period.

However, M-Lab=92s data doesn=92t quite square with that from other broadba= nd testing services. The Gigaom article claims a source confirmed that SamK= nows, a company that provides routers to consumers that track broadband spe= eds and whose data also contributes to the FCC=92s report, was not spotting the same trends. The same goes for= Ookla, the company behind the popular Speedtest.net website.

Thomas Gideon, the technology director at the Open Technology Institute, ad= dresses these kinds of discrepancies between different broadband tests by p= ointing to M-Lab=92s broad testing method and its overall openness. M-Lab= =92s network diagnostic test utilizes the Web 100 instrumentation package, and it generates roughly a half a ter= abyte per day, Gideon says. This data is collected from 12 different experi= ments run on networks that were volunteered for testing. All the raw data i= s open for review so others in the industry can contribute.

=93All of this openness is so that, like with a drug trial with any kind of= exploratory research, somebody else can take all of those inputs and ask g= ood, insightful questions about our results, can advance that working colla= boration, can use that data to try to see what insights it might provide on other aspects of the network that= are measured by the NDT tool,=94 Gideon says.

As for the differences between M-Lab=92s data and that of other providers, = Gideon says its tests capture a broad set of data from a point that reflect= s end users=92 network experience.

=93We=92re looking at the total state of the network as we find it, and loo= king for those organic findings as well, so we have our servers situated wh= ere they are so they=92re very similar to the source=92s choice that a cont= ent delivery network makes in terms of setting up its caching infrastructure or a content provider might make,=94 Gideon = says. =93So it=92s a little closer to the sorts of paths that are likely to= be involved when you=92re dealing with this question of customer experienc= e.=94

M-Lab=92s open standards don=92t necessarily make it more accurate than oth= er tests, however.

=93I don=92t think it=92s a question of accuracy, I think it=92s a question= of what insights specifically are you looking to glean,=94 Gideon says. = =93If you=92re looking to ask very narrow questions then you=92re going to = get very narrow answers.=94

What would make broadband performance data more accurate, and simultaneousl= y resolve the discrepancies between different tests, would be openness amon= g all organizations that perform these tests, Gideon says. The Open Technol= ogy Institute has worked with the FCC and others in the space to try to promote open standards for broadband= testing. Opening up the data is the only way to figure out why two tests o= f the same network may show different results, Gideon says.

=93You do it this way, you share your findings and your data and methodolog= y, in the way that you do so that other people can reproduce it, they can v= alidate your results,=94 he says. =93And they can also, in a case where thi= ngs don=92t quite line up, where there may be subsequent questions, they can collaborate and cooperate with you to im= prove over time so that you=92re getting better and better results, you=92r= e getting keener insights, you=92re just getting a better picture of what= =92s going on.=94

Gideon says SamKnows is very cooperative with its open policies, which M-La= b requires as a condition when it collaborates with other organizations. As= for other companies that test broadband, he says M-Lab is always open to d= iscussing partnerships that could go into deeper detail on performance trends.

However, direct collaboration wouldn=92t be as important if the FCC were to= establish standards for broadband testing, which Gideon says has become in= creasingly possible over the past few years. Crediting the FCC for bringing= together the public interest, the federal government, and the private sector to establish a =93good comparat= ive basis across technologies,=94 Gideon says standards for broadband testi= ng may not be that far away.

=93I think there are plenty of actors, including the FCC, working on standa= rds efforts, there=92s a lot of stuff in flight,=94 Gideon says. =93I would= n=92t presume to say that it=92s all the way there yet, but I would definit= ely like to see from our perspective more open standards around these sorts of things, because I think it invites more pe= ople into the field from all across the space: from private sector, from ac= ademia, from public interest. And it puts us on that same footing that that= we=92d like to be on in terms of open and comparable methodologies, open and comparable tools.=94

Colin Neagle covers emerging technologies and the startup scene for Netw= ork World. Follow him on Twitter @ntwrkwrldneagle and keep up with the Micr= osoft, Cisco and Open Source community blogs. Colin's email address is = ;cneagle@nww.com.

--_000_CF3B7202C6B46jasonlivingoodcablecomcastcom_-- From nobody Fri Mar 7 02:10:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65431A0133 for ; Fri, 7 Mar 2014 02:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-iAUNWLgj4x for ; Fri, 7 Mar 2014 02:10:39 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 391AC1A0107 for ; Fri, 7 Mar 2014 02:10:39 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id rp18so3951002iec.5 for ; Fri, 07 Mar 2014 02:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jjYtDuPh9smfZAH65dDrSULITFR1hRH8D0Eu/8pKFBY=; b=BujYLPiCSxlHwilcaq4EVQarbFvpVOmn3TF2MtTLKU//319jLkbBVBXCBDyZLuAAx+ uD0SEwcYxGW940Vo00oR+C1zsAhVlPuwm2MloLq+tiLWRmo8n7CxXjv3tLSeMxoBx09C VEJVPMkiSuUtLXEPrc5xJRid/vYCBJ/DR9zxPbKSt0TmZEU0+XhU3DmX0BuSY2LtRE8C kPK/9kdkr762Bkt6ypi9glgWP8w6AsOGUOMVTxrTX5cbqqTsB+we0XfMNwpmXBrwqF8m ekyhULtglPT4A9wOSjUtrYA59daakA4qKC8oxQzpBsigtj3kceB8/oPAbIqk2iPXnwUw +lXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jjYtDuPh9smfZAH65dDrSULITFR1hRH8D0Eu/8pKFBY=; b=FLr48nUA/UHbZYOVyeMBXOuetXSqUM3Jv5olXJJ+XjnOS4iYzosXRWdNxVT5rxHIFf hHBSDMzVNMZV03y+0npUE7ts8lb6si45JbBQakpU+Pt4+TZ7daQGL8NNblVcjhoBOQPd 93EDxypk2NJ+DX1tWYG2doWzHxp8yXVKuOX4AaE7juMV6/QsTJkUlMHS2caCnf8jnbDN pSiAsRA/3dslY/U8lT+Qvo/Ml93UZdlmda1QrCaFUTzY19YwbknGfoGzkyQVy7O/WGiT a1vztApGsBEPNb/qWU6LqB34glefVN7pMQqYGQpYJEDbKx0rzt0vy9ALfYT7aHFxPA71 KV7A== X-Gm-Message-State: ALoCoQlkbJXPDVRhaNemL4xErUjx5RggldWMuqGQFVt+Rt3HxhjRxhL26+p3N2pW3gchV9TSZSAAJKGopOBBXIGc1o89po3CYx14icWkSSVNp90FE5p671wx6f1zM1wF6KrG/PaZ1XfGAcqLdfUKuwGnwMkpXCIoei1qMhIpAXpP6ntPT4oKbeAelRkFsWcLtsgGbRkX9L6n MIME-Version: 1.0 X-Received: by 10.51.15.225 with SMTP id fr1mr1766597igd.5.1394187034730; Fri, 07 Mar 2014 02:10:34 -0800 (PST) Received: by 10.64.229.77 with HTTP; Fri, 7 Mar 2014 02:10:34 -0800 (PST) Date: Fri, 7 Mar 2014 02:10:34 -0800 Message-ID: From: Matt Mathis To: "lmap@ietf.org" Content-Type: multipart/alternative; boundary=001a1134bae4f4c54b04f40176dd Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2wgr6iehXzsUQPpMAFE0R5tnYtI Subject: [lmap] One example of a "passive measurement peer" 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, 07 Mar 2014 10:10:41 -0000 --001a1134bae4f4c54b04f40176dd Content-Type: text/plain; charset=UTF-8 >From the Internet Archive: http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/ Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. --001a1134bae4f4c54b04f40176dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From the Internet Archive:

http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/<= /a>

Thanks,
--MM--
The bes= t way to predict the future is to create it. =C2=A0- Alan Kay

Privac= y matters! =C2=A0We know from recent events that people are using our servi= ces to speak in defiance of unjust governments. =C2=A0 We treat privacy and= security as matters of life and death, because for some users, they are.
--001a1134bae4f4c54b04f40176dd-- From nobody Fri Mar 7 02:20:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2861A0178 for ; Fri, 7 Mar 2014 02:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 bU7bnLMvG71Q for ; Fri, 7 Mar 2014 02:20:49 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 88F1F1A012B for ; Fri, 7 Mar 2014 02:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7982; q=dns/txt; s=iport; t=1394187645; x=1395397245; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=T1JSv/9i3H5CEyCMlx2f2bHxCEMRVVxqkGedReg1BXk=; b=YHwvn4gdWj6Dz389/lgeB8AEf4oDsxtW18Jac3k+fh/SgYoGmIgXpdCV emEK8dBH8f1zjJRtx4AWOvu+Go/FGaxHLIz3fW/dFvlAsZlQaGRxG2s54 mmHVYda+DQbhzZB/5vSTCHzsKT/+r2dLqSpmpgsa3a4WIBuODWhpNy3Sr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAOicGVOtJXHA/2dsb2JhbABagkJEO1eDBrVEiGAZeRZ0giUBAQEEIwpcAgEIEQQBAQsdAwICAjAUCQgCBAESCBGHYA2uKqERF44qFiEBgm81gRQEpSeFRYMtgio X-IronPort-AV: E=Sophos;i="4.97,607,1389744000"; d="scan'208,217";a="308716115" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 07 Mar 2014 10:20:45 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s27AKi1p005182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 10:20:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 04:20:44 -0600 From: "Aamer Akhter (aakhter)" To: Matt Mathis , "lmap@ietf.org" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2J/qUPpc0XfkqSe2aNczXNrZrVaQOQ Date: Fri, 7 Mar 2014 10:20:43 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633C59954@xmb-rcd-x15.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.8.198] Content-Type: multipart/alternative; boundary="_000_75C0E47A1889264493A2DCB2869AC09633C59954xmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5xibpYK91Zvoi89YLfu4MYtWGPU Subject: Re: [lmap] One example of a "passive measurement peer" 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, 07 Mar 2014 10:20:54 -0000 --_000_75C0E47A1889264493A2DCB2869AC09633C59954xmbrcdx15ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hdHQsDQoNClRoaXMgaXMgYSBnb29kIGV4YW1wbGUgb2YgYSBtZWFzdXJlbWVudCBw ZWVy4oCUYW5kIHRvIGJlIGhvbmVzdCBoYWRu4oCZdCBjb25zaWRlcmVkIHRoaXMgdHlwZSBvZiB0 eWluZyBhcyBwYXJ0IG9mIHRoZSBMTUFQIHVzYWdlLiBJdCBjYW4gYmUgb2YgY291cnNlLg0KDQpJ IHdvdWxkIHRoaW5rIHRoYXQgdGFraW5nIHRoZSDigJhhY3RpdmXigJkgb3V0IG9mIOKAmGFjdGl2 ZSBtZWFzdXJlbWVudCBwZWVy4oCZIHdvdWxkIGFkZHJlc3MgdGhpcy4gSG93ZXZlciwgdGhlcmUg aXMgYW4gdW5rbm93biBvZiB3aHkgc29tZSBwZW9wbGUgd2VyZSBub3QgaGFwcHkgd2l0aCB0aGUg ZGlzdGluY3Rpb24gcmVtb3ZhbC4NCg0KYWENCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHQgTWF0aGlzDQpTZW50OiBGcmlkYXksIE1h cmNoIDcsIDIwMTQgNToxMSBBTQ0KVG86IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6IFtsbWFwXSBP bmUgZXhhbXBsZSBvZiBhICJwYXNzaXZlIG1lYXN1cmVtZW50IHBlZXIiDQoNCkZyb20gdGhlIElu dGVybmV0IEFyY2hpdmU6DQoNCmh0dHA6Ly93ZWIuYXJjaGl2ZS5vcmcvd2ViLzIwMDcxMDA1MTMw OTUzL2h0dHA6Ly93d3ctZGlkYy5sYmwuZ292L1NDTk0vPGh0dHA6Ly93ZWIuYXJjaGl2ZS5vcmcv d2ViLzIwMDcxMDA1MTMwOTUzL2h0dHA6L3d3dy1kaWRjLmxibC5nb3YvU0NOTS8+DQoNClRoYW5r cywNCi0tTU0tLQ0KVGhlIGJlc3Qgd2F5IHRvIHByZWRpY3QgdGhlIGZ1dHVyZSBpcyB0byBjcmVh dGUgaXQuICAtIEFsYW4gS2F5DQoNClByaXZhY3kgbWF0dGVycyEgIFdlIGtub3cgZnJvbSByZWNl bnQgZXZlbnRzIHRoYXQgcGVvcGxlIGFyZSB1c2luZyBvdXIgc2VydmljZXMgdG8gc3BlYWsgaW4g ZGVmaWFuY2Ugb2YgdW5qdXN0IGdvdmVybm1lbnRzLiAgIFdlIHRyZWF0IHByaXZhY3kgYW5kIHNl Y3VyaXR5IGFzIG1hdHRlcnMgb2YgbGlmZSBhbmQgZGVhdGgsIGJlY2F1c2UgZm9yIHNvbWUgdXNl cnMsIHRoZXkgYXJlLg0K --_000_75C0E47A1889264493A2DCB2869AC09633C59954xmbrcdx15ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBN YXR0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIGdvb2QgZXhhbXBsZSBvZiBhIG1lYXN1cmVtZW50IHBl ZXLigJRhbmQgdG8gYmUgaG9uZXN0IGhhZG7igJl0IGNvbnNpZGVyZWQgdGhpcyB0eXBlIG9mIHR5 aW5nIGFzIHBhcnQgb2YgdGhlIExNQVAgdXNhZ2UuIEl0IGNhbiBiZSBvZiBjb3Vyc2UuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgd291bGQgdGhpbmsgdGhhdCB0YWtpbmcgdGhlIOKAmGFjdGl2ZeKAmSBvdXQgb2Yg 4oCYYWN0aXZlIG1lYXN1cmVtZW50IHBlZXLigJkgd291bGQgYWRkcmVzcyB0aGlzLiBIb3dldmVy LCB0aGVyZSBpcyBhbiB1bmtub3duIG9mIHdoeSBzb21lIHBlb3BsZSB3ZXJlIG5vdCBoYXBweSB3 aXRoDQogdGhlIGRpc3RpbmN0aW9uIHJlbW92YWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXR0IE1hdGhpczxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIE1hcmNoIDcsIDIwMTQgNToxMSBBTTxicj4NCjxiPlRvOjwvYj4gbG1hcEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbG1hcF0gT25lIGV4YW1wbGUgb2YgYSAmcXVv dDtwYXNzaXZlIG1lYXN1cmVtZW50IHBlZXImcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSB0aGUgSW50ZXJuZXQgQXJjaGl2ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd2Vi LmFyY2hpdmUub3JnL3dlYi8yMDA3MTAwNTEzMDk1My9odHRwOi93d3ctZGlkYy5sYmwuZ292L1ND Tk0vIj5odHRwOi8vd2ViLmFyY2hpdmUub3JnL3dlYi8yMDA3MTAwNTEzMDk1My9odHRwOi8vd3d3 LWRpZGMubGJsLmdvdi9TQ05NLzwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1NTS0tPGJyPg0KVGhlIGJlc3Qgd2F5IHRvIHBy ZWRpY3QgdGhlIGZ1dHVyZSBpcyB0byBjcmVhdGUgaXQuICZuYnNwOy0gQWxhbiBLYXk8YnI+DQo8 YnI+DQpQcml2YWN5IG1hdHRlcnMhICZuYnNwO1dlIGtub3cgZnJvbSByZWNlbnQgZXZlbnRzIHRo YXQgcGVvcGxlIGFyZSB1c2luZyBvdXIgc2VydmljZXMgdG8gc3BlYWsgaW4gZGVmaWFuY2Ugb2Yg dW5qdXN0IGdvdmVybm1lbnRzLiAmbmJzcDsgV2UgdHJlYXQgcHJpdmFjeSBhbmQgc2VjdXJpdHkg YXMgbWF0dGVycyBvZiBsaWZlIGFuZCBkZWF0aCwgYmVjYXVzZSBmb3Igc29tZSB1c2VycywgdGhl eSBhcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_75C0E47A1889264493A2DCB2869AC09633C59954xmbrcdx15ciscoc_-- From nobody Mon Mar 10 06:31:37 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFD61A042A for ; Mon, 10 Mar 2014 06:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 e_H1NNG0Yy88 for ; Mon, 10 Mar 2014 06:31:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C7C031A0423 for ; Mon, 10 Mar 2014 06:31:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcMAGi+HVPGmAcV/2dsb2JhbABagkIjITtXgwalSQSQDYhcGYEBFnSCJQEBAQEDEhEKXAIBCA0EBAEBCx0DAgICMBQJCAIEARIIEQmHVwEMo3qKRqEYF44qFiEBgm81gRQEnzmFdIVFgy2CKw X-IronPort-AV: E=Sophos; i="4.97,623,1389762000"; d="scan'208,217"; a="45840167" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Mar 2014 09:31:17 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Mar 2014 09:18:23 -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; Mon, 10 Mar 2014 14:31:15 +0100 From: "Romascanu, Dan (Dan)" To: Matt Mathis , "lmap@ietf.org" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnw Date: Mon, 10 Mar 2014 13:31:15 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA2E44A926AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/m02kQQhB59AbQItn0RkQNCHzcRw Subject: Re: [lmap] One example of a "passive measurement peer" 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, 10 Mar 2014 13:31:35 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA2E44A926AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgb3RoZXIgZXhhbXBsZSBvZiBhIOKAmHBhc3NpdmUgbWFuYWdlbWVudCBwZWVy4oCZIGlzIGFu IFJUUCBwZWVyIHdoaWNoIHJlY2VpdmVzIFJUQ1AgbWVzc2FnZXMgYWJvdXQgdGhlIHN0YXRlIG9m IHRoZSBvdGhlciBzaWRlIG9mIHRoZSBjb25uZWN0aW9uIGFuZCB0aGUgcGFyYW1ldGVycyBvZiB0 aGUgcmVjZWl2ZWQgdHJhZmZpYyBhdCB0aGUgb3RoZXIgZW5kLiBBbGwgdGhlc2UgYXJlIHBhcnQg b2YgUlRQL1JUQ1AsIHRoZXJlIGlzIG5vIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGNvbnRyb2xs ZXIgYW5kIHRoZSBNUCwgc28gSSBiZWxpZXZlIGl0IGNhbiBiZSBjb25zaWRlcmVkIHBhc3NpdmUg aW4gTE1BUCB0ZXJtcy4NCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0KRnJvbTogbG1hcCBbbWFpbHRv OmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHQgTWF0aGlzDQpTZW50OiBG cmlkYXksIE1hcmNoIDA3LCAyMDE0IDEyOjExIFBNDQpUbzogbG1hcEBpZXRmLm9yZw0KU3ViamVj dDogW2xtYXBdIE9uZSBleGFtcGxlIG9mIGEgInBhc3NpdmUgbWVhc3VyZW1lbnQgcGVlciINCg0K RnJvbSB0aGUgSW50ZXJuZXQgQXJjaGl2ZToNCg0KaHR0cDovL3dlYi5hcmNoaXZlLm9yZy93ZWIv MjAwNzEwMDUxMzA5NTMvaHR0cDovL3d3dy1kaWRjLmxibC5nb3YvU0NOTS88aHR0cDovL3dlYi5h cmNoaXZlLm9yZy93ZWIvMjAwNzEwMDUxMzA5NTMvaHR0cDovd3d3LWRpZGMubGJsLmdvdi9TQ05N Lz4NCg0KVGhhbmtzLA0KLS1NTS0tDQpUaGUgYmVzdCB3YXkgdG8gcHJlZGljdCB0aGUgZnV0dXJl IGlzIHRvIGNyZWF0ZSBpdC4gIC0gQWxhbiBLYXkNCg0KUHJpdmFjeSBtYXR0ZXJzISAgV2Uga25v dyBmcm9tIHJlY2VudCBldmVudHMgdGhhdCBwZW9wbGUgYXJlIHVzaW5nIG91ciBzZXJ2aWNlcyB0 byBzcGVhayBpbiBkZWZpYW5jZSBvZiB1bmp1c3QgZ292ZXJubWVudHMuICAgV2UgdHJlYXQgcHJp dmFjeSBhbmQgc2VjdXJpdHkgYXMgbWF0dGVycyBvZiBsaWZlIGFuZCBkZWF0aCwgYmVjYXVzZSBm b3Igc29tZSB1c2VycywgdGhleSBhcmUuDQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA2E44A926AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IG90aGVy IGV4YW1wbGUgb2YgYSDigJhwYXNzaXZlIG1hbmFnZW1lbnQgcGVlcuKAmSBpcyBhbiBSVFAgcGVl ciB3aGljaCByZWNlaXZlcyBSVENQIG1lc3NhZ2VzIGFib3V0IHRoZSBzdGF0ZSBvZiB0aGUgb3Ro ZXIgc2lkZSBvZiB0aGUgY29ubmVjdGlvbiBhbmQgdGhlIHBhcmFtZXRlcnMNCiBvZiB0aGUgcmVj ZWl2ZWQgdHJhZmZpYyBhdCB0aGUgb3RoZXIgZW5kLiBBbGwgdGhlc2UgYXJlIHBhcnQgb2YgUlRQ L1JUQ1AsIHRoZXJlIGlzIG5vIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGNvbnRyb2xsZXIgYW5k IHRoZSBNUCwgc28gSSBiZWxpZXZlIGl0IGNhbiBiZSBjb25zaWRlcmVkIHBhc3NpdmUgaW4gTE1B UCB0ZXJtcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+TWF0dCBNYXRoaXM8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAw NywgMjAxNCAxMjoxMSBQTTxicj4NCjxiPlRvOjwvYj4gbG1hcEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbbG1hcF0gT25lIGV4YW1wbGUgb2YgYSAmcXVvdDtwYXNzaXZlIG1lYXN1cmVt ZW50IHBlZXImcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gdGhlIEludGVybmV0IEFyY2hpdmU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3dlYi5h cmNoaXZlLm9yZy93ZWIvMjAwNzEwMDUxMzA5NTMvaHR0cDovd3d3LWRpZGMubGJsLmdvdi9TQ05N LyI+aHR0cDovL3dlYi5hcmNoaXZlLm9yZy93ZWIvMjAwNzEwMDUxMzA5NTMvaHR0cDovL3d3dy1k aWRjLmxibC5nb3YvU0NOTS88L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tTU0tLTxicj4NClRoZSBiZXN0IHdheSB0byBwcmVk aWN0IHRoZSBmdXR1cmUgaXMgdG8gY3JlYXRlIGl0LiAmbmJzcDstIEFsYW4gS2F5PGJyPg0KPGJy Pg0KUHJpdmFjeSBtYXR0ZXJzISAmbmJzcDtXZSBrbm93IGZyb20gcmVjZW50IGV2ZW50cyB0aGF0 IHBlb3BsZSBhcmUgdXNpbmcgb3VyIHNlcnZpY2VzIHRvIHNwZWFrIGluIGRlZmlhbmNlIG9mIHVu anVzdCBnb3Zlcm5tZW50cy4gJm5ic3A7IFdlIHRyZWF0IHByaXZhY3kgYW5kIHNlY3VyaXR5IGFz IG1hdHRlcnMgb2YgbGlmZSBhbmQgZGVhdGgsIGJlY2F1c2UgZm9yIHNvbWUgdXNlcnMsIHRoZXkg YXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA2E44A926AZFFEXMB04globa_-- From nobody Tue Mar 11 06:29:56 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CF1A070A for ; Tue, 11 Mar 2014 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEpGe_pMNOPw for ; Tue, 11 Mar 2014 06:29:50 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2091A06A7 for ; Tue, 11 Mar 2014 06:29:49 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 8B8671A0C0C; Tue, 11 Mar 2014 14:29:42 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Trammell In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> Date: Tue, 11 Mar 2014 14:29:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98184277-C341-4622-ABED-990702554F8C@trammell.ch> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> To: Dan Romascanu X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ooyFOI8OTIhX_DKRc-6gy9EfSBE Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 13:29:53 -0000 hi Dan, Hm. I don't really consider this passive measurement -- we discussed = this a bit in the ippm registry design team, but I'm pretty sure there's = a difference between (1) metrics derived from the operation of a = protocol at one of the endpoints participating in it and (2) metrics = derived from the passive observation of packets emitted by those = protocols. I've always thought of passive measurement as the latter, and = (1) as something like "endpoint measurement", since metrics in (1) can = also be derived from internal state at each endpoint not synchronized = over the protocol or otherwise hard to derive.=20 One could say that a midpath observation point (i.e. any observation = point other than an endpoint) has as many "passive peers" as there are = observable senders and recipients, while an "endpoint measurement agent" = would have a single "endpoint peer". (This becomes a much more interesting distinction as soon as you = consider encrypting absolutely everything you can, of course. At that = point everything you're reduced to endpoint measurement for everything = other than the "envelope" and/or things you derive through behavioral = traffic analysis. But that's a separate discussion, I think.) In any case, I stand by my statement that I'd like to see peers defined = _only_ as much as is absolutely necessary to make sense of the resulting = control and reporting protocols. Cheers, Brian On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) = wrote: > My other example of a =91passive management peer=92 is an RTP peer = which receives RTCP messages about the state of the other side of the = connection and the parameters of the received traffic at the other end. = All these are part of RTP/RTCP, there is no interaction between the = controller and the MP, so I believe it can be considered passive in LMAP = terms. > =20 > Regards, > =20 > Dan > =20 > =20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > Sent: Friday, March 07, 2014 12:11 PM > To: lmap@ietf.org > Subject: [lmap] One example of a "passive measurement peer" > =20 > =46rom the Internet Archive: > =20 > = http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/ >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 06:35:29 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2A1A0674 for ; Tue, 11 Mar 2014 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGJHICJVneuR for ; Tue, 11 Mar 2014 06:35:25 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6912E1A0692 for ; Tue, 11 Mar 2014 06:35:25 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id BCD09554385; Tue, 11 Mar 2014 09:40:07 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 968D6F035A; Tue, 11 Mar 2014 09:35:19 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 11 Mar 2014 09:35:19 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Trammell , Dan Romascanu Date: Tue, 11 Mar 2014 09:35:01 -0400 Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: Ac89LgOr+cHXmseOTDCMJoXJvbH1ngAADHig Message-ID: <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> In-Reply-To: <98184277-C341-4622-ABED-990702554F8C@trammell.ch> 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: http://mailarchive.ietf.org/arch/msg/lmap/-xwOS1tenZzE86SzUx7Iqs1Zv7c Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 13:35:27 -0000 +1, I briefly tried to explain this to Dan in the back of the LMAP meeting room (while the meeting was still in-progress, I think). For me, it's a key distinction that the RTCP-reported end-point measurements have a priori knowledge of the stream in RTP (like active), while true passive measurements (at mid points) do not. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Tuesday, March 11, 2014 9:30 AM > To: Dan Romascanu > Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer" >=20 > hi Dan, >=20 > Hm. I don't really consider this passive measurement -- we discussed this > a bit in the ippm registry design team, but I'm pretty sure there's a > difference between (1) metrics derived from the operation of a protocol a= t > one of the endpoints participating in it and (2) metrics derived from the > passive observation of packets emitted by those protocols. I've always > thought of passive measurement as the latter, and (1) as something like > "endpoint measurement", since metrics in (1) can also be derived from > internal state at each endpoint not synchronized over the protocol or > otherwise hard to derive. >=20 > One could say that a midpath observation point (i.e. any observation poin= t > other than an endpoint) has as many "passive peers" as there are > observable senders and recipients, while an "endpoint measurement agent" > would have a single "endpoint peer". >=20 > (This becomes a much more interesting distinction as soon as you consider > encrypting absolutely everything you can, of course. At that point > everything you're reduced to endpoint measurement for everything other > than the "envelope" and/or things you derive through behavioral traffic > analysis. But that's a separate discussion, I think.) >=20 > In any case, I stand by my statement that I'd like to see peers defined > _only_ as much as is absolutely necessary to make sense of the resulting > control and reporting protocols. >=20 > Cheers, >=20 > Brian >=20 >=20 > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wrote= : >=20 > > My other example of a 'passive management peer' is an RTP peer which > receives RTCP messages about the state of the other side of the connectio= n > and the parameters of the received traffic at the other end. All these ar= e > part of RTP/RTCP, there is no interaction between the controller and the > MP, so I believe it can be considered passive in LMAP terms. > > > > Regards, > > > > Dan > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > Sent: Friday, March 07, 2014 12:11 PM > > To: lmap@ietf.org > > Subject: [lmap] One example of a "passive measurement peer" > > > > From the Internet Archive: > > > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/ > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy > and security as matters of life and death, because for some users, they > are. > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 06:36:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3231A0692 for ; Tue, 11 Mar 2014 06:36:42 -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 0VFh178zNKCp for ; Tue, 11 Mar 2014 06:36:40 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id DFC9C1A0674 for ; Tue, 11 Mar 2014 06:36:39 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2BDaUnu007303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 07:36:31 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8CADD1E007F; Tue, 11 Mar 2014 08:36:25 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5D4E31E007E; Tue, 11 Mar 2014 08:36:25 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s2BDaOZY026592; Tue, 11 Mar 2014 07:36:24 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s2BDaO1Y026578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 07:36:24 -0600 (MDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 08:36:24 -0500 From: "Bugenhagen, Michael K" To: "'Brian Trammell'" , "'Dan Romascanu'" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2Ay6PnPFJo/0eeoDd4KhTzipraqfuAgAGR5YD//6yJEA== Date: Tue, 11 Mar 2014 13:36:23 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> In-Reply-To: <98184277-C341-4622-ABED-990702554F8C@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5okqqtVQBye7YqeGrjWaRtB9raU Cc: 'Matt Mathis' , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 13:36:42 -0000 Just my 2 cents - but a word on future proofing...=20 The word passive is contextual... Which directly infers that we should "contextualize" it buy saying "x" pass= ive. As the technology disturbers add new dimensions that also contain passive/a= ctive stuff this is going to get more confused.... We're seriously having a problem with this at NFV / Cloud technology SDO's = where we've virtualized NIC's (Vnic's) and Vswitches both of which can be s= uspended (stopped).. It may prove difficult to do passive measurements on a virtual x,y,z compon= ent. Given Broadband Modems have this virtualized stuff, we should consider futu= re proofing our terms. Summary - contextualizing passive may be a great thing to future proof... f= or virtualization, those proof of concepts are in the works now. Cheers, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Tuesday, March 11, 2014 8:30 AM To: Dan Romascanu Cc: Matt Mathis; lmap@ietf.org Subject: Re: [lmap] One example of a "passive measurement peer" hi Dan, Hm. I don't really consider this passive measurement -- we discussed this a= bit in the ippm registry design team, but I'm pretty sure there's a differ= ence between (1) metrics derived from the operation of a protocol at one of= the endpoints participating in it and (2) metrics derived from the passive= observation of packets emitted by those protocols. I've always thought of = passive measurement as the latter, and (1) as something like "endpoint meas= urement", since metrics in (1) can also be derived from internal state at e= ach endpoint not synchronized over the protocol or otherwise hard to derive= .=20 One could say that a midpath observation point (i.e. any observation point = other than an endpoint) has as many "passive peers" as there are observable= senders and recipients, while an "endpoint measurement agent" would have a= single "endpoint peer". (This becomes a much more interesting distinction as soon as you consider e= ncrypting absolutely everything you can, of course. At that point everythin= g you're reduced to endpoint measurement for everything other than the "env= elope" and/or things you derive through behavioral traffic analysis. But th= at's a separate discussion, I think.) In any case, I stand by my statement that I'd like to see peers defined _on= ly_ as much as is absolutely necessary to make sense of the resulting contr= ol and reporting protocols. Cheers, Brian On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wrote: > My other example of a 'passive management peer' is an RTP peer which rece= ives RTCP messages about the state of the other side of the connection and = the parameters of the received traffic at the other end. All these are part= of RTP/RTCP, there is no interaction between the controller and the MP, so= I believe it can be considered passive in LMAP terms. > =20 > Regards, > =20 > Dan > =20 > =20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > Sent: Friday, March 07, 2014 12:11 PM > To: lmap@ietf.org > Subject: [lmap] One example of a "passive measurement peer" > =20 > From the Internet Archive: > =20 > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/ >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > Privacy matters! We know from recent events that people are using our se= rvices to speak in defiance of unjust governments. We treat privacy and s= ecurity as matters of life and death, because for some users, they are. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 06:38:09 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39A1A072D for ; Tue, 11 Mar 2014 06:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 veWd8Qzb6Xjq for ; Tue, 11 Mar 2014 06:38:03 -0700 (PDT) Received: from nm21-vm10.access.bullet.mail.bf1.yahoo.com (nm21-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.137]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3C1A0674 for ; Tue, 11 Mar 2014 06:38:02 -0700 (PDT) Received: from [66.196.81.161] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 13:37:56 -0000 Received: from [66.196.81.146] by tm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 13:37:56 -0000 Received: from [127.0.0.1] by omp1022.access.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 13:37:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 761398.32549.bm@omp1022.access.mail.bf1.yahoo.com Received: (qmail 59399 invoked by uid 60001); 11 Mar 2014 13:37:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394545076; bh=u+Nh60HbMNs/X7wsSGd92rvq15tTfQ5Q0LpeFxrkiN4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NUUf80H/+sXlkLBtqkxdW7iKFlL3IZjMnUQ3/7U1bKvxuWN4n6Bh5MAQeoc1uPTFfMLxCBr6oSXdhSw81bANiFx+b6fm6rymETeGIFa/S30wRJyu6qO/3lXRCl1fstA8z0sMLYt8xA4sRes6EsZ8hw/75qO1yHhbHOnkpQr/fW0= X-YMail-OSG: J1kC1s0VM1kQTuPmCopnKAN_LMCj_oS7gQmob0BNTrCzY_K 21eRSlNsQnBlbb7OQfPmj7Wgci995Se8Bx49PiGep2.UjqoF5e3mV65CS4OL k0c4jAEzRidSQXqchUH1ju69j4F3SxPkNDbkU5dkYS0eY4c0e6UZHk0tks7l e9zCg46ncP4UpPP_gVQJMJqy0doylCeuvEGObeRMu2IIqY46r8HrNbJnlXzH wvyP8YIOkE2.FynareInQ6KqmLx.RWPF_0Foep1dJoihZdkkzM7_TOeE9ted 5bBgdNvTXj6qKaoKqoucXg32AG.4qidvvbR7B6snRFYGE5GdpHynY41NLxpN 6WJ5ZRNSM3mK1Ffy1wN6NJK5.equjc4rDXh25iUwRG__v9EeU8zHgvTNcxmf QzzBlDWdmStxINw87jTbynHo5sA.tsSgKrBty8TvP25jlxelP9TPs_Ffd4hD ACj8BS3l6fi8UTNARL94pegtSYSOYP8WG41as.W_hMp9WmYqbftqxqIH5Pvn PX2AY644LEqDK.N7q4DRVltZkV.989tiWDRzsIwxnm.SMVURCPNe0RZIbH7R EpMVQaXEkkz3X1S0AfABQDKJ52JgaIytQFoz_rySkEB8Vewol0NbCBqTRwNw h3eprRaY__htAWQRoXuJeu26r1DbUDXsybAcKSi_sEXc_PdGoDsWJ7lsAB3m _d1PamQoPRv9Ft8gb4VpswLY4NQGAeJJ5RfqybUMAiAW.3kFj9FwG_J6OkEn 9.ObYq13bjJ7bY10DuFi7FUzVlMDemehfxviQgG073TBdNBvS8dl.goYP4om tMHbEM7..CPg5i__ujFpDtw-- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 06:37:56 PDT X-Rocket-MIMEInfo: 002.001, UGFzc2l2ZSAob3IgaHlicmlkKSBtZWFzdXJlbWVudHMgbmVlZCBub3QgYmUgYXQgIm1pZHBvaW50cyIuIMKgIFRoZXkgbWF5IGJlIGF0ICJlbmQgcG9pbnRzIi4gwqAgVGhhdCBpcyB0aGUgY2xpZW50IGl0c2VsZi4KwqAKVGhhbmtzLAoKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206ICJNT1JUT04sIEFMRlJFRCBDIChBTCkiIDxhY21vcnRvbkBhdHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> Message-ID: <1394545076.60507.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 06:37:56 -0700 (PDT) From: Nalini Elkins To: "MORTON, ALFRED C \(AL\)" , Brian Trammell , Dan Romascanu In-Reply-To: <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1478178976-1394545076=:60507" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BEg64qsoFyCpTsKYsnfnZic4lkc Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 13:38:06 -0000 --1619178251-1478178976-1394545076=:60507 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Passive (or hybrid) measurements need not be at "midpoints". =A0 They may b= e at "end points". =A0 That is the client itself.=0A=A0=0AThanks,=0A=0A=0AN= alini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.= com=0A=0A=0A=0A________________________________=0A From: "MORTON, ALFRED C = (AL)" =0ATo: Brian Trammell ; Dan Romas= canu =0ACc: Matt Mathis ; "lmap= @ietf.org" =0ASent: Tuesday, March 11, 2014 6:35 AM=0ASubje= ct: Re: [lmap] One example of a "passive measurement peer"=0A =0A=0A+1, I b= riefly tried to explain this to Dan in the back of the LMAP=0Ameeting room = (while the meeting was still in-progress, I think).=0A=0AFor me, it's a key= distinction that the RTCP-reported end-point=0Ameasurements have a priori = knowledge of the stream in RTP (like active),=0Awhile true passive measurem= ents (at mid points) do not.=0A=0AAl=0A=0A> -----Original Message-----=0A> = From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell=0A> S= ent: Tuesday, March 11, 2014 9:30 AM=0A> To: Dan Romascanu=0A> Cc: Matt Mat= his; lmap@ietf.org=0A> Subject: Re: [lmap] One example of a "passive measur= ement peer"=0A> =0A> hi Dan,=0A> =0A> Hm. I don't really consider this pass= ive measurement -- we discussed this=0A> a bit in the ippm registry design = team, but I'm pretty sure there's a=0A> difference between (1) metrics deri= ved from the operation of a protocol at=0A> one of the endpoints participat= ing in it and (2) metrics derived from the=0A> passive observation of packe= ts emitted by those protocols. I've always=0A> thought of passive measureme= nt as the latter, and (1) as something like=0A> "endpoint measurement", sin= ce metrics in (1) can also be derived from=0A> internal state at each endpo= int not synchronized over the protocol or=0A> otherwise hard to derive.=0A>= =0A> One could say that a midpath observation point (i.e. any observation = point=0A> other than an endpoint) has as many "passive peers" as there are= =0A> observable senders and recipients, while an "endpoint measurement agen= t"=0A> would have a single "endpoint peer".=0A> =0A> (This becomes a much m= ore interesting distinction as soon as you consider=0A> encrypting absolute= ly everything you can, of course. At that point=0A> everything you're reduc= ed to endpoint measurement for everything other=0A> than the "envelope" and= /or things you derive through behavioral traffic=0A> analysis. But that's a= separate discussion, I think.)=0A> =0A> In any case, I stand by my stateme= nt that I'd like to see peers defined=0A> _only_ as much as is absolutely n= ecessary to make sense of the resulting=0A> control and reporting protocols= .=0A> =0A> Cheers,=0A> =0A> Brian=0A> =0A> =0A> On 10 Mar 2014, at 14:31, R= omascanu, Dan (Dan) wrote:=0A> =0A> > My other example= of a 'passive management peer' is an RTP peer which=0A> receives RTCP mess= ages about the state of the other side of the connection=0A> and the parame= ters of the received traffic at the other end. All these are=0A> part of RT= P/RTCP, there is no interaction between the controller and the=0A> MP, so I= believe it can be considered passive in LMAP terms.=0A> >=0A> > Regards,= =0A> >=0A> > Dan=0A> >=0A> >=0A> > From: lmap [mailto:lmap-bounces@ietf.org= ] On Behalf Of Matt Mathis=0A> > Sent: Friday, March 07, 2014 12:11 PM=0A> = > To: lmap@ietf.org=0A> > Subject: [lmap] One example of a "passive measure= ment peer"=0A> >=0A> > From the Internet Archive:=0A> >=0A> > http://web.ar= chive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/=0A> >=0A> > Than= ks,=0A> > --MM--=0A> > The best way to predict the future is to create it.= =A0 - Alan Kay=0A> >=0A> > Privacy matters!=A0 We know from recent events t= hat people are using our=0A> services to speak in defiance of unjust govern= ments.=A0 We treat privacy=0A> and security as matters of life and death, = because for some users, they=0A> are.=0A> > _______________________________= ________________=0A> > lmap mailing list=0A> > lmap@ietf.org=0A> > https://= www.ietf.org/mailman/listinfo/lmap=0A> =0A> _______________________________= ________________=0A> lmap mailing list=0A> lmap@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/lmap=0A=0A_________________________________________= ______=0Almap mailing list=0Almap@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/lmap --1619178251-1478178976-1394545076=:60507 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Passive (or hybrid) m= easurements need not be at "midpoints".   They may be at "end points".=   That is the client itself.
 
=
Thanks,


Nalini Elkins
Inside Products,= Inc.
(831) 659-8360
www.insidethestack.com

= From: "MORTON, ALFRED C (AL= )" <acmorton@att.com>
To: Brian Trammell <ietf@trammell.ch>; Dan Romascanu <dromas= ca@avaya.com>
Cc: M= att Mathis <mattmathis@google.com>; "lmap@ietf.org" <lmap@ietf.org>
= Sent: Tuesday, March 11, 2= 014 6:35 AM
Subject: R= e: [lmap] One example of a "passive measurement peer"

=0A+1, I briefly tried to explain this to = Dan in the back of the LMAP
meeting room (while the meeting was still in= -progress, I think).

For me, it's a key distinction that the RTCP-re= ported end-point
measurements have a priori knowledge of the stream in R= TP (like active),
while true passive measurements (at mid points) do not= .

Al

> -----Original Message-----
> From: lmap [mail= to:lmap-bounces@ietf.org] On Behalf Of Brian Trammell
> Se= nt: Tuesday, March 11, 2014 9:30 AM
> To: Dan Romascanu
> Cc: M= att Mathis; lmap@ietf.org
> Subject: Re: [lmap] One example of a "passive = measurement peer"
>
> hi Dan,
>
> Hm. I don't rea= lly consider this passive measurement -- we discussed this
> a bit in= the ippm registry design team, but I'm pretty sure there's a
> difference between (1) metrics derived f= rom the operation of a protocol at
> one of the endpoints participati= ng in it and (2) metrics derived from the
> passive observation of pa= ckets emitted by those protocols. I've always
> thought of passive me= asurement as the latter, and (1) as something like
> "endpoint measur= ement", since metrics in (1) can also be derived from
> internal stat= e at each endpoint not synchronized over the protocol or
> otherwise = hard to derive.
>
> One could say that a midpath observation p= oint (i.e. any observation point
> other than an endpoint) has as man= y "passive peers" as there are
> observable senders and recipients, w= hile an "endpoint measurement agent"
> would have a single "endpoint = peer".
>
> (This becomes a much more interesting distinction a= s soon as you consider
> encrypting absolutely everything you can, of course. At that point
> everything you're reduced to endpoin= t measurement for everything other
> than the "envelope" and/or thing= s you derive through behavioral traffic
> analysis. But that's a sepa= rate discussion, I think.)
>
> In any case, I stand by my stat= ement that I'd like to see peers defined
> _only_ as much as is absol= utely necessary to make sense of the resulting
> control and reportin= g protocols.
>
> Cheers,
>
> Brian
>
&g= t;
> On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) <dromasca@= avaya.com> wrote:
>
> > My other example of a 'passi= ve management peer' is an RTP peer which
> receives RTCP messages abo= ut the state of the other side of the connection
> and the parameters= of the received traffic at the other end. All these are
> part of RTP/RTCP, there is no interaction between the controller and the
> M= P, so I believe it can be considered passive in LMAP terms.
> >> > Regards,
> >
> > Dan
> >
> >=
> > From: lmap [mailto:lmap-bounces@ietf.org] On Behal= f Of Matt Mathis
> > Sent: Friday, March 07, 2014 12:11 PM
>= > To: lmap@ietf.org
> > Subject: [lmap] One example of a "passive m= easurement peer"
> >
> > From the Internet Archive:
&g= t; >
> > http://web.archive.org/web/20071005130953/http://www-d= idc.lbl.gov/SCNM/
> >
> > Thanks,
> > --MM--
= > > The best way to predict the future is to create it.  - Alan = Kay
> >
> > Privacy matters!  We know from recent events that people are using our
> services to speak in defiance of = unjust governments.  We treat privacy
> and security as matters= of life and death, because for some users, they
> are.
> > = _______________________________________________
> > lmap mailing l= ist
> > lmap@ietf.org
> > https://www.ietf.org/mailman/listinfo/= lmap
>
> _______________________________________________> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mail= man/listinfo/lmap

______________________________________________= _
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mail= man/listinfo/lmap


--1619178251-1478178976-1394545076=:60507-- From nobody Tue Mar 11 07:05:20 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44921A0729 for ; Tue, 11 Mar 2014 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 Iy4SSk4OwOm8 for ; Tue, 11 Mar 2014 07:05:14 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDC61A045C for ; Tue, 11 Mar 2014 07:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19045; q=dns/txt; s=iport; t=1394546708; x=1395756308; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dHR+TVuD8YZPBiVb9FjMY+EUEloUmhKyt/6Q3eleSGY=; b=FEW6JoQ/QncnDwpzSj0hrRkM570tXBEXjgp054k/P0YdhMGBblOV1L6j MByPD4yhWY5dSx7Dp3ZVEKon4JSuPQGH31EPV1klcw1gS15MuxXbZdI4n 4qJU8IpQ+IcFyo0S0gRwDFLcBfogZ87J4DG6nBQC4XLl23Nq5/M4vv7fe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0FAMcWH1OtJXG8/2dsb2JhbABXA4JCRDtXuFqIXIEeFnSCJQEBAQQBAQEqHCULDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIEYdgDdEpF44rASAMAQIBBgEGAwiDE4EUBKUthUWDLYIr X-IronPort-AV: E=Sophos; i="4.97,631,1389744000"; d="scan'208,217"; a="26554004" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-3.cisco.com with ESMTP; 11 Mar 2014 14:05:06 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2BE56lM012270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 14:05:06 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 09:05:05 -0500 From: "Aamer Akhter (aakhter)" To: Nalini Elkins , "MORTON, ALFRED C (AL)" , Brian Trammell , Dan Romascanu Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2J/qUPpc0XfkqSe2aNczXNrZraqfuAgAGR5YCAAAF+gIAAANAA//+xzIA= Date: Tue, 11 Mar 2014 14:05:05 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633C700C3@xmb-rcd-x15.cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <1394545076.60507.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1394545076.60507.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.25.28] Content-Type: multipart/alternative; boundary="_000_75C0E47A1889264493A2DCB2869AC09633C700C3xmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9FOve8Pr0e6t5Rlra0hxLTFapWQ Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 14:05:18 -0000 --_000_75C0E47A1889264493A2DCB2869AC09633C700C3xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Passive (or hybrid) measurements need not be at "midpoints". They may be= at "end points". That is the client itself." Indeed this can be wireshark on the end system, and that would be a passive= measurement on an end system. But I don't think that is what Al and Brian were getting at. SIP, RTP, RTCP= are part of one set of joined interactions. This is not too dissimilar fr= om a TWAMP/OWAMP + whatever traffic they generate at that point in my mind.= So if we had to pick between active and passive, it's much on the active s= ide. But keep in mind that we are really talking about a user application. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins Sent: Tuesday, March 11, 2014 9:38 AM To: MORTON, ALFRED C (AL); Brian Trammell; Dan Romascanu Cc: Matt Mathis; lmap@ietf.org Subject: Re: [lmap] One example of a "passive measurement peer" Passive (or hybrid) measurements need not be at "midpoints". They may be = at "end points". That is the client itself. Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: "MORTON, ALFRED C (AL)" > To: Brian Trammell >; Dan Romasca= nu > Cc: Matt Mathis >; "lma= p@ietf.org" > Sent: Tuesday, March 11, 2014 6:35 AM Subject: Re: [lmap] One example of a "passive measurement peer" +1, I briefly tried to explain this to Dan in the back of the LMAP meeting room (while the meeting was still in-progress, I think). For me, it's a key distinction that the RTCP-reported end-point measurements have a priori knowledge of the stream in RTP (like active), while true passive measurements (at mid points) do not. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] O= n Behalf Of Brian Trammell > Sent: Tuesday, March 11, 2014 9:30 AM > To: Dan Romascanu > Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer" > > hi Dan, > > Hm. I don't really consider this passive measurement -- we discussed this > a bit in the ippm registry design team, but I'm pretty sure there's a > difference between (1) metrics derived from the operation of a protocol a= t > one of the endpoints participating in it and (2) metrics derived from the > passive observation of packets emitted by those protocols. I've always > thought of passive measurement as the latter, and (1) as something like > "endpoint measurement", since metrics in (1) can also be derived from > internal state at each endpoint not synchronized over the protocol or > otherwise hard to derive. > > One could say that a midpath observation point (i.e. any observation poin= t > other than an endpoint) has as many "passive peers" as there are > observable senders and recipients, while an "endpoint measurement agent" > would have a single "endpoint peer". > > (This becomes a much more interesting distinction as soon as you consider > encrypting absolutely everything you can, of course. At that point > everything you're reduced to endpoint measurement for everything other > than the "envelope" and/or things you derive through behavioral traffic > analysis. But that's a separate discussion, I think.) > > In any case, I stand by my statement that I'd like to see peers defined > _only_ as much as is absolutely necessary to make sense of the resulting > control and reporting protocols. > > Cheers, > > Brian > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > wrote: > > > My other example of a 'passive management peer' is an RTP peer which > receives RTCP messages about the state of the other side of the connectio= n > and the parameters of the received traffic at the other end. All these ar= e > part of RTP/RTCP, there is no interaction between the controller and the > MP, so I believe it can be considered passive in LMAP terms. > > > > Regards, > > > > Dan > > > > > > From: lmap [mailto:lmap-bounces@ietf.org]= On Behalf Of Matt Mathis > > Sent: Friday, March 07, 2014 12:11 PM > > To: lmap@ietf.org > > Subject: [lmap] One example of a "passive measurement peer" > > > > From the Internet Archive: > > > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/= > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy > and security as matters of life and death, because for some users, they > are. > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_75C0E47A1889264493A2DCB2869AC09633C700C3xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Passive (or hybrid) measurements need not be at "= ;midpoints".   They may be at "end points".   That is the client itself.= ”

 <= /p>

From: lmap [= mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Tuesday, March 11, 2014 9:38 AM
To: MORTON, ALFRED C (AL); Brian Trammell; Dan Romascanu
Cc: Matt Mathis; lmap@ietf.org
Subject: Re: [lmap] One example of a "passive measurement peer&= quot;

 

Passive (or hybrid)= measurements need not be at "midpoints".   They may be at &= quot;end points".   That is the client itself.<= /p>

 

Thanks,<= /span>

 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

 

From: "MORTON, ALFRED C (AL)" = <acmorton@att.com>
To: Brian Trammell <ietf@tram= mell.ch>; Dan Romascanu <dr= omasca@avaya.com>
Cc: Matt Mathis <mattmat= his@google.com>; "lmap@ietf.or= g" <lmap@ietf.org>
Sent: Tuesday, March 11, 2014 6:35 AM
Subject: Re: [lmap] One example of a "passive measurement peer&= quot;


+1, I briefly tried to explain this to Dan in the back of the LMAP
meeting room (while the meeting was still in-progress, I think).

For me, it's a key distinction that the RTCP-reported end-point
measurements have a priori knowledge of the stream in RTP (like active), while true passive measurements (at mid points) do not.

Al

> -----Original Message-----
> From: lmap [mailto:lmap-bounc= es@ietf.org] On Behalf Of Brian Trammell
> Sent: Tuesday, March 11, 2014 9:30 AM
> To: Dan Romascanu
> Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer&qu= ot;
>
> hi Dan,
>
> Hm. I don't really consider this passive measurement -- we discussed t= his
> a bit in the ippm registry design team, but I'm pretty sure there's a<= br> > difference between (1) metrics derived from the operation of a protoco= l at
> one of the endpoints participating in it and (2) metrics derived from = the
> passive observation of packets emitted by those protocols. I've always=
> thought of passive measurement as the latter, and (1) as something lik= e
> "endpoint measurement", since metrics in (1) can also be der= ived from
> internal state at each endpoint not synchronized over the protocol or<= br> > otherwise hard to derive.
>
> One could say that a midpath observation point (i.e. any observation p= oint
> other than an endpoint) has as many "passive peers" as there= are
> observable senders and recipients, while an "endpoint measurement= agent"
> would have a single "endpoint peer".
>
> (This becomes a much more interesting distinction as soon as you consi= der
> encrypting absolutely everything you can, of course. At that point
> everything you're reduced to endpoint measurement for everything other=
> than the "envelope" and/or things you derive through behavio= ral traffic
> analysis. But that's a separate discussion, I think.)
>
> In any case, I stand by my statement that I'd like to see peers define= d
> _only_ as much as is absolutely necessary to make sense of the resulti= ng
> control and reporting protocols.
>
> Cheers,
>
> Brian
>
>
> On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
>
> > My other example of a 'passive management peer' is an RTP peer wh= ich
> receives RTCP messages about the state of the other side of the connec= tion
> and the parameters of the received traffic at the other end. All these= are
> part of RTP/RTCP, there is no interaction between the controller and t= he
> MP, so I believe it can be considered passive in LMAP terms.
> >
> > Regards,
> >
> > Dan
> >
> >
> > From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of Matt Mathis
> > Sent: Friday, March 07, 2014 12:11 PM
> > To: lmap@ietf.org
> > Subject: [lmap] One example of a "passive measurement peer&q= uot;
> >
> > From the Internet Archive:
> >
> > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/=
> >
> > Thanks,
> > --MM--
> > The best way to predict the future is to create it.  - Alan = Kay
> >
> > Privacy matters!  We know from recent events that people are= using our
> services to speak in defiance of unjust governments.  We treat pr= ivacy
> and security as matters of life and death, because for some users, the= y
> are.
> > _______________________________________________
> > lmap mailing list
> > lmap@ietf.org
> > https://www.ietf.org/mailman/listinfo/lmap
>
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap

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

--_000_75C0E47A1889264493A2DCB2869AC09633C700C3xmbrcdx15ciscoc_-- From nobody Tue Mar 11 07:21:23 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319B1A044B for ; Tue, 11 Mar 2014 07:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 bt_MjJlvdrMX for ; Tue, 11 Mar 2014 07:21:15 -0700 (PDT) Received: from nm18-vm4.access.bullet.mail.bf1.yahoo.com (nm18-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1041A0423 for ; Tue, 11 Mar 2014 07:21:15 -0700 (PDT) Received: from [66.196.81.166] by nm18.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 14:21:09 -0000 Received: from [66.196.81.136] by tm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 14:21:09 -0000 Received: from [127.0.0.1] by omp1012.access.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 14:21:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 449030.3628.bm@omp1012.access.mail.bf1.yahoo.com Received: (qmail 81060 invoked by uid 60001); 11 Mar 2014 14:21:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394547668; bh=7HoSKqFqPN5bLKUy/J3d+GkWbJW7YgTchU9QNWujqQc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SA80qg0uDDZEf6pQLF0qJHHlimX/lQKWFONLMZRLc/SbQsyVsho1Qpx8NK5gvNm6YuC80bd3ml392IQ5cixETxg2YULjffothGVdmG7jL7uHA8krfO34LloZvJGMM2+ANulSyfggEME+fu6d2YW306PYmE0dEujJrGoJ8qetvPQ= X-YMail-OSG: fZl_SEoVM1nsn7EfK29x9k.V6BFmMGDS.LT471nkx4Ep.y_ fqgzf6H9UOhxqyIdABXH8TLq6GhqU2_nvWVh3tnu6bln_wAiNL0vU9KfNqZN Yl8qh0oiHDKh.gGDgGs6ex1hBVMxycfDSWwxAhstP7uX4jMjXOj88uDn8vWY wUu76RFXaayvDn5kTx0oAxuETZhlzBqj7m3c.5nAet6wtNS6uDPC2RQxysh0 eocgDxky5iZkir4uhjhz2bP5.ioEbT5pcykQh8A9qHdqnPQJoy_jaATKQDzo 9mnaPY0pFJCZsH1sOqvivu3n5gDlY6vAsfRKcyWrDKoJ.4fVq2fqCAM76RcA 2BQy6r3VlNYPlDyulavEFH0B02j6Qg7yufey_YUJOnYijx_VaYVAU0p7vvxP RiZ0ZgZKg9ZUITfvUzeSZY5JlR5Z7xQDUJS.WbCuS3JQH6cQ3_ulpKJsSMMx kTnomW8sPh3S6zRx_HBcUh.Ct8Jt1qsj8e5BQouDViDhswPyYB3TtCIMfLwa nFGEPYtMi6QuwbSi5ao4din.1Cyffdbj6o.12Q6mPIZPlheCg2kQJl4nmviW 1EYuuCOGhrYs_GG0f2RfDoc7LIOk.54UBuvGw2XW9.Km2lKryC6mpFPtL9St K_MAh.8CNLd7FUvXrPDsGNyhaOP56PA1Cs8snmdqdEZv7Qk31IG520hXQNw7 PUuo1wPaNiv4P.5yzkZahJKda68d2ZKMcJJVy7vSs.hm_b.3TuqV7WcnvJzI CSTugaOTrfCsvtReRdt90kxkcdJpHUtz2M59tbt1a75aQDAMN2ePmtH6uwDY s__GmDCc36u4yPyM- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 07:21:08 PDT X-Rocket-MIMEInfo: 002.001, QWdyZWVkLgrCoApUaGFua3MsCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogQWFtZXIgQWtodGVyIChhYWtodGVyKSA8YWFraHRlckBjaXNjby5jb20.ClRvOiBOYWxpbmkgRWxraW5zIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT47ICJNT1JUT04sIEFMRlJFRCBDIChBTCkiIDxhY21vcnRvbkBhdHQuY29tPjsgQnJpYW4gVHJhbW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <1394545076.60507.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <75C0E47A1889264493A2DCB2869AC09633C700C3@xmb-rcd-x15.cisco.com> Message-ID: <1394547668.24970.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 07:21:08 -0700 (PDT) From: Nalini Elkins To: "Aamer Akhter \(aakhter\)" , "MORTON, ALFRED C \(AL\)" , Brian Trammell , Dan Romascanu In-Reply-To: <75C0E47A1889264493A2DCB2869AC09633C700C3@xmb-rcd-x15.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1447816140-1394547668=:24970" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FArz3MfqCDV13Bbtg82Ytnjdtd0 Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:21:21 -0000 ---1551098171-1447816140-1394547668=:24970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agreed.=0A=C2=A0=0AThanks,=0A=0A=0ANalini Elkins=0AInside Products, Inc.=0A= (831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________________= ________=0A From: Aamer Akhter (aakhter) =0ATo: Nalini E= lkins ; "MORTON, ALFRED C (AL)" ; Brian Trammell ; Dan Romascanu =0ACc: Matt Mathis ; "lmap@ietf.org" =0ASent: Tuesday, March 11, 2014 7:05 AM=0ASubject: Re: [lmap] One e= xample of a "passive measurement peer"=0A =0A=0A=0A =0A=E2=80=9CPassive (or= hybrid) measurements need not be at "midpoints". =C2=A0 They may be at "en= d points". =C2=A0 That is the client itself.=E2=80=9D=0A=C2=A0=0AIndeed thi= s can be wireshark on the end system, and that would be a passive measureme= nt on an end system.=0A=C2=A0=0ABut I don=E2=80=99t think that is what Al a= nd Brian were getting at. SIP, RTP, RTCP are part of one set of joined inte= ractions. =C2=A0This is not too dissimilar from a TWAMP/OWAMP + whatever tr= affic they generate at that point in my mind. So if we had to pick between = active and passive, it=E2=80=99s much on the active side. =0A=C2=A0=0ABut k= eep in mind that we are really talking about a user application. =C2=A0=0A= =C2=A0=0A=C2=A0=0AFrom:lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nal= ini Elkins=0ASent: Tuesday, March 11, 2014 9:38 AM=0ATo: MORTON, ALFRED C (= AL); Brian Trammell; Dan Romascanu=0ACc: Matt Mathis; lmap@ietf.org=0ASubje= ct: Re: [lmap] One example of a "passive measurement peer"=0A=C2=A0=0APassi= ve (or hybrid) measurements need not be at "midpoints". =C2=A0 They may be = at "end points". =C2=A0 That is the client itself.=0A=C2=A0=0AThanks,=0A=C2= =A0=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insideth= estack.com=0A=C2=A0=0A=0A________________________________=0A =0AFrom:"MORTO= N, ALFRED C (AL)" =0ATo: Brian Trammell ; Dan Romascanu =0ACc: Matt Mathis ; "lmap@ietf.org" =0ASent: Tuesday, March 11, 2014 6:3= 5 AM=0ASubject: Re: [lmap] One example of a "passive measurement peer"=0A= =0A+1, I briefly tried to explain this to Dan in the back of the LMAP=0Amee= ting room (while the meeting was still in-progress, I think).=0A=0AFor me, = it's a key distinction that the RTCP-reported end-point=0Ameasurements have= a priori knowledge of the stream in RTP (like active),=0Awhile true passiv= e measurements (at mid points) do not.=0A=0AAl=0A=0A> -----Original Message= -----=0A> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Tram= mell=0A> Sent: Tuesday, March 11, 2014 9:30 AM=0A> To: Dan Romascanu=0A> Cc= : Matt Mathis; lmap@ietf.org=0A> Subject: Re: [lmap] One example of a "pass= ive measurement peer"=0A> =0A> hi Dan,=0A> =0A> Hm. I don't really consider= this passive measurement -- we discussed this=0A> a bit in the ippm regist= ry design team, but I'm pretty sure there's a=0A> difference between (1) me= trics derived from the operation of a protocol at=0A> one of the endpoints = participating in it and (2) metrics derived from the=0A> passive observatio= n of packets emitted by those protocols. I've always=0A> thought of passive= measurement as the latter, and (1) as something like=0A> "endpoint measure= ment", since metrics in (1) can also be derived from=0A> internal state at = each endpoint not synchronized over the protocol or=0A> otherwise hard to d= erive.=0A> =0A> One could say that a midpath observation point (i.e. any ob= servation point=0A> other than an endpoint) has as many "passive peers" as = there are=0A> observable senders and recipients, while an "endpoint measure= ment agent"=0A> would have a single "endpoint peer".=0A> =0A> (This becomes= a much more interesting distinction as soon as you consider=0A> encrypting= absolutely everything you can, of course. At that point=0A> everything you= 're reduced to endpoint measurement for everything other=0A> than the "enve= lope" and/or things you derive through behavioral traffic=0A> analysis. But= that's a separate discussion, I think.)=0A> =0A> In any case, I stand by m= y statement that I'd like to see peers defined=0A> _only_ as much as is abs= olutely necessary to make sense of the resulting=0A> control and reporting = protocols.=0A> =0A> Cheers,=0A> =0A> Brian=0A> =0A> =0A> On 10 Mar 2014, at= 14:31, Romascanu, Dan (Dan) wrote:=0A> =0A> > My othe= r example of a 'passive management peer' is an RTP peer which=0A> receives = RTCP messages about the state of the other side of the connection=0A> and t= he parameters of the received traffic at the other end. All these are=0A> p= art of RTP/RTCP, there is no interaction between the controller and the=0A>= MP, so I believe it can be considered passive in LMAP terms.=0A> >=0A> > R= egards,=0A> >=0A> > Dan=0A> >=0A> >=0A> > From: lmap [mailto:lmap-bounces@i= etf.org] On Behalf Of Matt Mathis=0A> > Sent: Friday, March 07, 2014 12:11 = PM=0A> > To: lmap@ietf.org=0A> > Subject: [lmap] One example of a "passive = measurement peer"=0A> >=0A> > From the Internet Archive:=0A> >=0A> > http:/= /web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/=0A> >=0A>= > Thanks,=0A> > --MM--=0A> > The best way to predict the future is to crea= te it.=C2=A0 - Alan Kay=0A> >=0A> > Privacy matters!=C2=A0 We know from rec= ent events that people are using our=0A> services to speak in defiance of u= njust governments.=C2=A0 We treat privacy=0A> and security as matters of li= fe and death, because for some users, they=0A> are.=0A> > _________________= ______________________________=0A> > lmap mailing list=0A> > lmap@ietf.org= =0A> > https://www.ietf.org/mailman/listinfo/lmap=0A> =0A> ________________= _______________________________=0A> lmap mailing list=0A> lmap@ietf.org=0A>= https://www.ietf.org/mailman/listinfo/lmap=0A=0A__________________________= _____________________=0Almap mailing list=0Almap@ietf.org=0Ahttps://www.iet= f.org/mailman/listinfo/lmap=0A=0A=0A_______________________________________= ________=0Almap mailing list=0Almap@ietf.org=0Ahttps://www.ietf.org/mailman= /listinfo/lmap ---1551098171-1447816140-1394547668=:24970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agreed.
<= div>
 
Thanks,


Nalini= Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.co= m

From: Aamer Akhter (aakhter) <aakhter@cisco.com>
To: Nalini Elkins <nalini.elkins@insi= dethestack.com>; "MORTON, ALFRED C (AL)" <acmorton@att.com>; Brian= Trammell <ietf@trammell.ch>; Dan Romascanu <dromasca@avaya.com>= ;
Cc: Matt Mathis <mattmathis@google.com>; "lmap@ietf.org" <lmap@ietf.org>
= Sent: Tuesday, March 11, 2= 014 7:05 AM
Subject: R= e: [lmap] One example of a "passive measurement peer"

=0A
=0A=0A =0A = =0A=0A=0A
=0A
=0A
=E2=80=9CPassive (or hybrid) measurements need not be at "midpoints". =   They=0A may be at "end points".   That is the client itself.=E2=80=9D
= =0A
 
=0A
Indeed this can be wireshark on the end syste= m, and that would be a passive measurement on an end system.
= =0A
 
=0A
But I don=E2=80=99t think that is what Al and= Brian were getting at. SIP, RTP, RTCP are part of one set of joined intera= ctions.  This is not=0A too dissimilar from a TWAMP/OWAMP + whatever t= raffic they generate at that point in my mind. So if we had to pick between= active and passive, it=E2=80=99s much on the active side.=0A
= =0A
 
=0A
But keep in mind that we are really talking a= bout a user application.  
=0A
 
=0A
<= span style=3D"font-size:11.0pt;color:#1F497D;">  
=0A=0A
=0A
From: lmap [m= ailto:lmap-bounces@ietf.org]=0AOn Behalf Of Nalini Elkins
=0AS= ent: Tuesday, March 11, 2014 9:38 AM
=0ATo: MORTON, ALFRED C = (AL); Brian Trammell; Dan Romascanu
=0ACc: Matt Mathis; lmap@ietf= .org
=0ASubject: Re: [lmap] One example of a "passive measurement= peer"
=0A
=0A
=0A
 
=0A
=0A
=0A
Passive (or hybrid= ) measurements need not be at "midpoints".   They may be at "end point= s".   That is the client itself.
=0A
=0A
=0A 
=0A
=0A
=0A
Thanks,
=0A
=0A
=0A
 
=0A
=0A
=0A
Nali= ni Elkins
=0AInside Products, Inc.
=0A(831) 659-8360
=0Awww.ins= idethestack.com
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A<= /span>
=0A
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
=0ATo: Bria= n Trammell <ietf@trammell.ch>; Da= n Romascanu <dromasca@avaya.com&= gt;=0A
=0ACc: Matt Mathis <mattmathis@google.com>; "lmap@ietf.= org" <lmap@ietf.org>=0A
=0ASe= nt: Tuesday, March 11, 2014 6:35 AM
=0ASubject: Re: [lmap] On= e example of a "passive measurement peer"
=0A
=0A
=0A

=0A+1, I briefly tried to explain this to Dan in the back of the LMAP=
=0Ameeting room (while the meeting was still in-progress, I think).
= =0A
=0AFor me, it's a key distinction that the RTCP-reported end-point=0Ameasurements have a priori knowledge of the stream in RTP (like active= ),
=0Awhile true passive measurements (at mid points) do not.
=0A
= =0AAl
=0A
=0A> -----Original Message-----
=0A> From: lmap [m= ailto:lmap-bounces@ietf.org= ] On Behalf Of Brian Trammell
=0A> Sent: Tuesday, March 11, 2014 9:30= AM
=0A> To: Dan Romascanu
=0A> Cc: Matt Mathis; lmap@ietf.org
=0A> Subject: Re: [lmap] One example of= a "passive measurement peer"
=0A>
=0A> hi Dan,
=0A> =0A> Hm. I don't really consider this passive measurement -- we discuss= ed this
=0A> a bit in the ippm registry design team, but I'm pretty s= ure there's a
=0A> difference between (1) metrics derived from the op= eration of a protocol at
=0A> one of the endpoints participating in i= t and (2) metrics derived from the
=0A> passive observation of packet= s emitted by those protocols. I've always
=0A> thought of passive mea= surement as the latter, and (1) as something like
=0A> "endpoint meas= urement", since metrics in (1) can also be derived from
=0A> internal= state at each endpoint not synchronized over the protocol or
=0A> ot= herwise hard to derive.
=0A>
=0A> One could say that a midpath= observation point (i.e. any observation point
=0A> other than an end= point) has as many "passive peers" as there are
=0A> observable sende= rs and recipients, while an "endpoint measurement agent"
=0A> would h= ave a single "endpoint peer".
=0A>
=0A> (This becomes a much m= ore interesting distinction as soon as you consider
=0A> encrypting a= bsolutely everything you can, of course. At that point
=0A> everythin= g you're reduced to endpoint measurement for everything other
=0A> th= an the "envelope" and/or things you derive through behavioral traffic
= =0A> analysis. But that's a separate discussion, I think.)
=0A> =0A> In any case, I stand by my statement that I'd like to see peers d= efined
=0A> _only_ as much as is absolutely necessary to make sense o= f the resulting
=0A> control and reporting protocols.
=0A>
= =0A> Cheers,
=0A>
=0A> Brian
=0A>
=0A>
=0A= > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
=0A>
=0A> &= gt; My other example of a 'passive management peer' is an RTP peer which=0A> receives RTCP messages about the state of the other side of the co= nnection
=0A> and the parameters of the received traffic at the other= end. All these are
=0A> part of RTP/RTCP, there is no interaction be= tween the controller and the
=0A> MP, so I believe it can be consider= ed passive in LMAP terms.
=0A> >
=0A> > Regards,
=0A&g= t; >
=0A> > Dan
=0A> >
=0A> >
=0A> >= From: lmap [mailto:lmap-bounces@= ietf.org] On Behalf Of Matt Mathis
=0A> > Sent: Friday, March = 07, 2014 12:11 PM
=0A> > To: lmap@ietf.o= rg
=0A> > Subject: [lmap] One example of a "passive measuremen= t peer"
=0A> >
=0A> > From the Internet Archive:
=0A&g= t; >
=0A> > =0Ahttp:= //web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/
= =0A> >
=0A> > Thanks,
=0A> > --MM--
=0A> >= The best way to predict the future is to create it.  - Alan Kay
= =0A> >
=0A> > Privacy matters!  We know from recent eve= nts that people are using our
=0A> services to speak in defiance of u= njust governments.  We treat privacy
=0A> and security as matter= s of life and death, because for some users, they
=0A> are.
=0A>= ; > _______________________________________________
=0A> > lmap= mailing list
=0A> > lmap@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/lmap
=0A>
=0A> _______________________________________________=0A> lmap mailing list
=0A> lmap@ietf.o= rg
=0A> https://www.ietf.org/mailman/listinfo/lmap=
=0A
=0A_______________________________________________
=0Alma= p mailing list
=0Almap@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/lmap
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A
_______________________________________________
lmap mailing listlmap@ie= tf.org
https://www.ietf.org/mailman/listinfo/lmap


---1551098171-1447816140-1394547668=:24970-- From nobody Tue Mar 11 07:59:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6591A1A0759 for ; Tue, 11 Mar 2014 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 Zygq2YAeaIDa for ; Tue, 11 Mar 2014 07:59:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id CBB891A0757 for ; Tue, 11 Mar 2014 07:59:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 684061108; Tue, 11 Mar 2014 15:59:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Lu6qL_c4E8_p; Tue, 11 Mar 2014 15:59:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Mar 2014 15:59:18 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ADA02002F; Tue, 11 Mar 2014 15:59:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g_3nVecKI7kc; Tue, 11 Mar 2014 15:59:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F5B32002C; Tue, 11 Mar 2014 15:59:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 731D52BB0034; Tue, 11 Mar 2014 15:59:13 +0100 (CET) Date: Tue, 11 Mar 2014 15:59:13 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140311145912.GA78853@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Brian Trammell' , 'Dan Romascanu' , 'Matt Mathis' , "'lmap@ietf.org'" References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YLzaKXc42Ind-Hph-580ZB7WueI Cc: 'Brian Trammell' , "'lmap@ietf.org'" , 'Matt Mathis' , 'Dan Romascanu' Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 14:59:29 -0000 Hi, I do not think we need the term 'passive measurement peer' in the framework so perhaps the best thing is to not spent cycles trying to define it. /js On Tue, Mar 11, 2014 at 01:36:23PM +0000, Bugenhagen, Michael K wrote: > Just my 2 cents - but a word on future proofing... > > The word passive is contextual... > > Which directly infers that we should "contextualize" it buy saying "x" passive. > As the technology disturbers add new dimensions that also contain passive/active stuff this is going to get more confused.... > > We're seriously having a problem with this at NFV / Cloud technology SDO's where we've virtualized NIC's (Vnic's) and Vswitches both of which can be suspended (stopped).. > > It may prove difficult to do passive measurements on a virtual x,y,z component. > Given Broadband Modems have this virtualized stuff, we should consider future proofing our terms. > > Summary - contextualizing passive may be a great thing to future proof... for virtualization, those proof of concepts are in the works now. > > Cheers, > Mike > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Tuesday, March 11, 2014 8:30 AM > To: Dan Romascanu > Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer" > > hi Dan, > > Hm. I don't really consider this passive measurement -- we discussed this a bit in the ippm registry design team, but I'm pretty sure there's a difference between (1) metrics derived from the operation of a protocol at one of the endpoints participating in it and (2) metrics derived from the passive observation of packets emitted by those protocols. I've always thought of passive measurement as the latter, and (1) as something like "endpoint measurement", since metrics in (1) can also be derived from internal state at each endpoint not synchronized over the protocol or otherwise hard to derive. > > One could say that a midpath observation point (i.e. any observation point other than an endpoint) has as many "passive peers" as there are observable senders and recipients, while an "endpoint measurement agent" would have a single "endpoint peer". > > (This becomes a much more interesting distinction as soon as you consider encrypting absolutely everything you can, of course. At that point everything you're reduced to endpoint measurement for everything other than the "envelope" and/or things you derive through behavioral traffic analysis. But that's a separate discussion, I think.) > > In any case, I stand by my statement that I'd like to see peers defined _only_ as much as is absolutely necessary to make sense of the resulting control and reporting protocols. > > Cheers, > > Brian > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wrote: > > > My other example of a 'passive management peer' is an RTP peer which receives RTCP messages about the state of the other side of the connection and the parameters of the received traffic at the other end. All these are part of RTP/RTCP, there is no interaction between the controller and the MP, so I believe it can be considered passive in LMAP terms. > > > > Regards, > > > > Dan > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > Sent: Friday, March 07, 2014 12:11 PM > > To: lmap@ietf.org > > Subject: [lmap] One example of a "passive measurement peer" > > > > From the Internet Archive: > > > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SCNM/ > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- 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 Mar 11 08:04:07 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C045B1A0479 for ; Tue, 11 Mar 2014 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 Z83r_eR1HKAV for ; Tue, 11 Mar 2014 08:03:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 95A791A0759 for ; Tue, 11 Mar 2014 08:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5441; q=dns/txt; s=iport; t=1394550233; x=1395759833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3mTsxYvTIoibRS+BtnNP2HYEXvBccSfDvLXuDXyuxf8=; b=DX7FnyQjXYgETXK8qQ0caRYBf4FQBVK5TnwTNr1kBnsBEH4humDd8TtE eFoQFaCSeqL9IcWqrfvMoLmbH0FkdoChofzXC8MZkgETsFneCif6ZdeTF ierE6o/Rm7WOmbLSm5j8cuQ6Feq3bzHzNe4Op1F+6CjRsVcix8GxKatFD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAH4lH1OtJV2Y/2dsb2JhbABTBAODBjtXwTaBHhZ0giUBAQEEAQEBNzQLDAICAgEIDgIBBAEBAQoUCQcbDAsUCQgCBA4FCBECh14N0R4XBI4QFyEQBwYLgxOBFASlLYVFgy2BaSMf X-IronPort-AV: E=Sophos;i="4.97,631,1389744000"; d="scan'208";a="309546400" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 11 Mar 2014 15:03:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2BF3hqL003918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 15:03:43 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 10:03:42 -0500 From: "Aamer Akhter (aakhter)" To: Juergen Schoenwaelder , "Bugenhagen, Michael K" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2J/qUPpc0XfkqSe2aNczXNrZraqfuAgAGR5YCAAAHfgIAAFyWA//+tLNA= Date: Tue, 11 Mar 2014 15:03:42 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> In-Reply-To: <20140311145912.GA78853@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.25.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l2Cda85HcUpqs3o4u_tIwWfKdVs Cc: 'Brian Trammell' , 'Dan Romascanu' , 'Matt Mathis' , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 15:04:05 -0000 I agree on the removal of 'passive' in 'passive measurement peer' but if I = remember correctly where was some discontent with just that as the solution= .=20 Do we have any clarity on where the discontent was coming from=20 -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Tuesday, March 11, 2014 10:59 AM To: Bugenhagen, Michael K Cc: 'Brian Trammell'; 'lmap@ietf.org'; 'Matt Mathis'; 'Dan Romascanu' Subject: Re: [lmap] One example of a "passive measurement peer" Hi, I do not think we need the term 'passive measurement peer' in the framework= so perhaps the best thing is to not spent cycles trying to define it. /js On Tue, Mar 11, 2014 at 01:36:23PM +0000, Bugenhagen, Michael K wrote: > Just my 2 cents - but a word on future proofing...=20 >=20 > The word passive is contextual... >=20 > Which directly infers that we should "contextualize" it buy saying "x" pa= ssive. > As the technology disturbers add new dimensions that also contain passive= /active stuff this is going to get more confused.... >=20 > We're seriously having a problem with this at NFV / Cloud technology SDO'= s where we've virtualized NIC's (Vnic's) and Vswitches both of which can be= suspended (stopped).. >=20 > It may prove difficult to do passive measurements on a virtual x,y,z comp= onent. > Given Broadband Modems have this virtualized stuff, we should consider fu= ture proofing our terms. >=20 > Summary - contextualizing passive may be a great thing to future proof...= for virtualization, those proof of concepts are in the works now. >=20 > Cheers, > Mike >=20 >=20 >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Tuesday, March 11, 2014 8:30 AM > To: Dan Romascanu > Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer" >=20 > hi Dan, >=20 > Hm. I don't really consider this passive measurement -- we discussed this= a bit in the ippm registry design team, but I'm pretty sure there's a diff= erence between (1) metrics derived from the operation of a protocol at one = of the endpoints participating in it and (2) metrics derived from the passi= ve observation of packets emitted by those protocols. I've always thought o= f passive measurement as the latter, and (1) as something like "endpoint me= asurement", since metrics in (1) can also be derived from internal state at= each endpoint not synchronized over the protocol or otherwise hard to deri= ve.=20 >=20 > One could say that a midpath observation point (i.e. any observation poin= t other than an endpoint) has as many "passive peers" as there are observab= le senders and recipients, while an "endpoint measurement agent" would have= a single "endpoint peer". >=20 > (This becomes a much more interesting distinction as soon as you=20 > consider encrypting absolutely everything you can, of course. At that=20 > point everything you're reduced to endpoint measurement for everything=20 > other than the "envelope" and/or things you derive through behavioral=20 > traffic analysis. But that's a separate discussion, I think.) >=20 > In any case, I stand by my statement that I'd like to see peers defined _= only_ as much as is absolutely necessary to make sense of the resulting con= trol and reporting protocols. >=20 > Cheers, >=20 > Brian >=20 >=20 > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wrote= : >=20 > > My other example of a 'passive management peer' is an RTP peer which re= ceives RTCP messages about the state of the other side of the connection an= d the parameters of the received traffic at the other end. All these are pa= rt of RTP/RTCP, there is no interaction between the controller and the MP, = so I believe it can be considered passive in LMAP terms. > > =20 > > Regards, > > =20 > > Dan > > =20 > > =20 > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > Sent: Friday, March 07, 2014 12:11 PM > > To: lmap@ietf.org > > Subject: [lmap] One example of a "passive measurement peer" > > =20 > > From the Internet Archive: > > =20 > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SC > > NM/ > >=20 > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > >=20 > > Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy and= security as matters of life and death, because for some users, they are. > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > 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 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 08:08:19 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9771A0499 for ; Tue, 11 Mar 2014 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 gjce-5rrd24h for ; Tue, 11 Mar 2014 08:08:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id B9BA71A0479 for ; Tue, 11 Mar 2014 08:08:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C1063F64; Tue, 11 Mar 2014 16:08:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ogGEEG0DLJtA; Tue, 11 Mar 2014 16:08:03 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Mar 2014 16:08:03 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95D1720033; Tue, 11 Mar 2014 16:08:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id chjsKdBUW8_E; Tue, 11 Mar 2014 16:08:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 983B32002C; Tue, 11 Mar 2014 16:08:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AA6FB2BB00BC; Tue, 11 Mar 2014 16:08:00 +0100 (CET) Date: Tue, 11 Mar 2014 16:08:00 +0100 From: Juergen Schoenwaelder To: "Aamer Akhter (aakhter)" Message-ID: <20140311150800.GA78913@elstar.local> Mail-Followup-To: "Aamer Akhter (aakhter)" , "Bugenhagen, Michael K" , 'Brian Trammell' , "'lmap@ietf.org'" , 'Matt Mathis' , 'Dan Romascanu' References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8i6j4OfdEfummIQVErtI_Rp8T0c Cc: 'Brian Trammell' , 'Matt Mathis' , 'Dan Romascanu' , "Bugenhagen, Michael K" , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 15:08:15 -0000 Hi, I do not recall having seen 'passive measurement peer' in the framework nor do I recall that it was suggested that this term be added. At the meeting, we discussed to remove 'active' from a new proposed definition of Measurement Agent (and I though we were slowly converging to this change - but I am biased of course). /js On Tue, Mar 11, 2014 at 03:03:42PM +0000, Aamer Akhter (aakhter) wrote: > I agree on the removal of 'passive' in 'passive measurement peer' but if I remember correctly where was some discontent with just that as the solution. > > Do we have any clarity on where the discontent was coming from > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 11, 2014 10:59 AM > To: Bugenhagen, Michael K > Cc: 'Brian Trammell'; 'lmap@ietf.org'; 'Matt Mathis'; 'Dan Romascanu' > Subject: Re: [lmap] One example of a "passive measurement peer" > > Hi, > > I do not think we need the term 'passive measurement peer' in the framework so perhaps the best thing is to not spent cycles trying to define it. > > /js > > On Tue, Mar 11, 2014 at 01:36:23PM +0000, Bugenhagen, Michael K wrote: > > Just my 2 cents - but a word on future proofing... > > > > The word passive is contextual... > > > > Which directly infers that we should "contextualize" it buy saying "x" passive. > > As the technology disturbers add new dimensions that also contain passive/active stuff this is going to get more confused.... > > > > We're seriously having a problem with this at NFV / Cloud technology SDO's where we've virtualized NIC's (Vnic's) and Vswitches both of which can be suspended (stopped).. > > > > It may prove difficult to do passive measurements on a virtual x,y,z component. > > Given Broadband Modems have this virtualized stuff, we should consider future proofing our terms. > > > > Summary - contextualizing passive may be a great thing to future proof... for virtualization, those proof of concepts are in the works now. > > > > Cheers, > > Mike > > > > > > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > > Sent: Tuesday, March 11, 2014 8:30 AM > > To: Dan Romascanu > > Cc: Matt Mathis; lmap@ietf.org > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > hi Dan, > > > > Hm. I don't really consider this passive measurement -- we discussed this a bit in the ippm registry design team, but I'm pretty sure there's a difference between (1) metrics derived from the operation of a protocol at one of the endpoints participating in it and (2) metrics derived from the passive observation of packets emitted by those protocols. I've always thought of passive measurement as the latter, and (1) as something like "endpoint measurement", since metrics in (1) can also be derived from internal state at each endpoint not synchronized over the protocol or otherwise hard to derive. > > > > One could say that a midpath observation point (i.e. any observation point other than an endpoint) has as many "passive peers" as there are observable senders and recipients, while an "endpoint measurement agent" would have a single "endpoint peer". > > > > (This becomes a much more interesting distinction as soon as you > > consider encrypting absolutely everything you can, of course. At that > > point everything you're reduced to endpoint measurement for everything > > other than the "envelope" and/or things you derive through behavioral > > traffic analysis. But that's a separate discussion, I think.) > > > > In any case, I stand by my statement that I'd like to see peers defined _only_ as much as is absolutely necessary to make sense of the resulting control and reporting protocols. > > > > Cheers, > > > > Brian > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wrote: > > > > > My other example of a 'passive management peer' is an RTP peer which receives RTCP messages about the state of the other side of the connection and the parameters of the received traffic at the other end. All these are part of RTP/RTCP, there is no interaction between the controller and the MP, so I believe it can be considered passive in LMAP terms. > > > > > > Regards, > > > > > > Dan > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > > Sent: Friday, March 07, 2014 12:11 PM > > > To: lmap@ietf.org > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > From the Internet Archive: > > > > > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/SC > > > NM/ > > > > > > Thanks, > > > --MM-- > > > The best way to predict the future is to create it. - Alan Kay > > > > > > Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > 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 -- 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 Mar 11 08:09:10 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF6F1A0479 for ; Tue, 11 Mar 2014 08:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 ARJwV75i9_Ut for ; Tue, 11 Mar 2014 08:09:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B57651A0757 for ; Tue, 11 Mar 2014 08:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6781; q=dns/txt; s=iport; t=1394550538; x=1395760138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sGfrXJBbUh0W3ri5gimoumoARKxR9icWkLhJexSHj18=; b=TWxsnj52/xc1gUNCIZI6I+0LbtgGhya9Rms1Neb+p7ZC/85NLHhYNrHo CUptdVfBIF+2c3V2KRzJTOGCb77+Xg/uLE23JITj67qkC1IEEsKd+i8kV qMy5pCUWdRcF9RqjeenM6uHFpGVOpCV4NuK0nEkqITvINJlhQH5RB1ege c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFALMlH1OtJV2a/2dsb2JhbABTBAODBjtXwTaBHhZ0giUBAQEEAQEBNzQLDAICAgEIDgIBBAEBAQoUCQcbDAsUCQgCBA4FCBECh14N0R4XBI4QFyEQBwYLgxOBFASqcoMtgWkjHw X-IronPort-AV: E=Sophos;i="4.97,631,1389744000"; d="scan'208";a="26571577" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 11 Mar 2014 15:08:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2BF8w8k015257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 15:08:58 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.137]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 10:08:58 -0500 From: "Aamer Akhter (aakhter)" To: Juergen Schoenwaelder Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2J/qUPpc0XfkqSe2aNczXNrZraqfuAgAGR5YCAAAHfgIAAFyWA//+tLNCAAFVIAP//rGBQ Date: Tue, 11 Mar 2014 15:08:58 +0000 Message-ID: <75C0E47A1889264493A2DCB2869AC09633C70973@xmb-rcd-x15.cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <20140311150800.GA78913@elstar.local> In-Reply-To: <20140311150800.GA78913@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.25.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/c9O1-P64n44j3FV04BrrR0QpkXA Cc: 'Brian Trammell' , 'Matt Mathis' , 'Dan Romascanu' , "Bugenhagen, Michael K" , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 15:09:08 -0000 My mistake. You are right it was 'active' in 'active measurement peer'.=20 Aa (in need of coffee)=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, March 11, 2014 11:08 AM To: Aamer Akhter (aakhter) Cc: Bugenhagen, Michael K; 'Brian Trammell'; 'lmap@ietf.org'; 'Matt Mathis'= ; 'Dan Romascanu' Subject: Re: [lmap] One example of a "passive measurement peer" Hi, I do not recall having seen 'passive measurement peer' in the framework nor= do I recall that it was suggested that this term be added. At the meeting, we discussed to remove 'active' from a new proposed definit= ion of Measurement Agent (and I though we were slowly converging to this ch= ange - but I am biased of course). /js On Tue, Mar 11, 2014 at 03:03:42PM +0000, Aamer Akhter (aakhter) wrote: > I agree on the removal of 'passive' in 'passive measurement peer' but if = I remember correctly where was some discontent with just that as the soluti= on.=20 >=20 > Do we have any clarity on where the discontent was coming from >=20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Tuesday, March 11, 2014 10:59 AM > To: Bugenhagen, Michael K > Cc: 'Brian Trammell'; 'lmap@ietf.org'; 'Matt Mathis'; 'Dan Romascanu' > Subject: Re: [lmap] One example of a "passive measurement peer" >=20 > Hi, >=20 > I do not think we need the term 'passive measurement peer' in the framewo= rk so perhaps the best thing is to not spent cycles trying to define it. >=20 > /js >=20 > On Tue, Mar 11, 2014 at 01:36:23PM +0000, Bugenhagen, Michael K wrote: > > Just my 2 cents - but a word on future proofing...=20 > >=20 > > The word passive is contextual... > >=20 > > Which directly infers that we should "contextualize" it buy saying "x" = passive. > > As the technology disturbers add new dimensions that also contain passi= ve/active stuff this is going to get more confused.... > >=20 > > We're seriously having a problem with this at NFV / Cloud technology SD= O's where we've virtualized NIC's (Vnic's) and Vswitches both of which can = be suspended (stopped).. > >=20 > > It may prove difficult to do passive measurements on a virtual x,y,z co= mponent. > > Given Broadband Modems have this virtualized stuff, we should consider = future proofing our terms. > >=20 > > Summary - contextualizing passive may be a great thing to future proof.= .. for virtualization, those proof of concepts are in the works now. > >=20 > > Cheers, > > Mike > >=20 > >=20 > >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian=20 > > Trammell > > Sent: Tuesday, March 11, 2014 8:30 AM > > To: Dan Romascanu > > Cc: Matt Mathis; lmap@ietf.org > > Subject: Re: [lmap] One example of a "passive measurement peer" > >=20 > > hi Dan, > >=20 > > Hm. I don't really consider this passive measurement -- we discussed th= is a bit in the ippm registry design team, but I'm pretty sure there's a di= fference between (1) metrics derived from the operation of a protocol at on= e of the endpoints participating in it and (2) metrics derived from the pas= sive observation of packets emitted by those protocols. I've always thought= of passive measurement as the latter, and (1) as something like "endpoint = measurement", since metrics in (1) can also be derived from internal state = at each endpoint not synchronized over the protocol or otherwise hard to de= rive.=20 > >=20 > > One could say that a midpath observation point (i.e. any observation po= int other than an endpoint) has as many "passive peers" as there are observ= able senders and recipients, while an "endpoint measurement agent" would ha= ve a single "endpoint peer". > >=20 > > (This becomes a much more interesting distinction as soon as you=20 > > consider encrypting absolutely everything you can, of course. At=20 > > that point everything you're reduced to endpoint measurement for=20 > > everything other than the "envelope" and/or things you derive=20 > > through behavioral traffic analysis. But that's a separate=20 > > discussion, I think.) > >=20 > > In any case, I stand by my statement that I'd like to see peers defined= _only_ as much as is absolutely necessary to make sense of the resulting c= ontrol and reporting protocols. > >=20 > > Cheers, > >=20 > > Brian > >=20 > >=20 > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) wro= te: > >=20 > > > My other example of a 'passive management peer' is an RTP peer which = receives RTCP messages about the state of the other side of the connection = and the parameters of the received traffic at the other end. All these are = part of RTP/RTCP, there is no interaction between the controller and the MP= , so I believe it can be considered passive in LMAP terms. > > > =20 > > > Regards, > > > =20 > > > Dan > > > =20 > > > =20 > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > > Sent: Friday, March 07, 2014 12:11 PM > > > To: lmap@ietf.org > > > Subject: [lmap] One example of a "passive measurement peer" > > > =20 > > > From the Internet Archive: > > > =20 > > > http://web.archive.org/web/20071005130953/http://www-didc.lbl.gov/ > > > SC > > > NM/ > > >=20 > > > Thanks, > > > --MM-- > > > The best way to predict the future is to create it. - Alan Kay > > >=20 > > > Privacy matters! We know from recent events that people are using ou= r services to speak in defiance of unjust governments. We treat privacy a= nd security as matters of life and death, because for some users, they are. > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > --=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 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 11 08:16:04 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871E11A0757 for ; Tue, 11 Mar 2014 08:16:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 oJ6CWPLpWspM for ; Tue, 11 Mar 2014 08:15:59 -0700 (PDT) Received: from nm14-vm4.access.bullet.mail.bf1.yahoo.com (nm14-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7181A0746 for ; Tue, 11 Mar 2014 08:15:59 -0700 (PDT) Received: from [66.196.81.156] by nm14.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:15:53 -0000 Received: from [66.196.81.133] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:15:53 -0000 Received: from [127.0.0.1] by omp1009.access.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:15:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 315101.64449.bm@omp1009.access.mail.bf1.yahoo.com Received: (qmail 65351 invoked by uid 60001); 11 Mar 2014 15:15:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394550952; bh=oPWaEiBo0h07Jkg+zhqnk4UjIZp5TFtXg2qOr3A9if4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Apnq85k/A2IanbAoGJXc0Tl2UYyYELch0nAcZVTTqNNfoo2q2ePn4XM06vo4D4DaDrJQMfFqVAOXIrH4n2DauCljODKK/zKgtvo54+VdzLNe0SN/MQM5nIswoDbeRYlEI8fze8svSEAXQ0VR7+/EC7nzLBnD5+XOj2T2SrJGhPI= X-YMail-OSG: HzcbiOIVM1ldw2tcGIblL5NBF7ywZm1oUXAYoN2NfcuenGW MSuXrg.WGkZU2..On.09X4DL2yUph7ana4313_0ftGuAwIDYos.WV4Ae6Iva zaATVa_tntKuMWZrT9Np.cdfCZFdb0SwbjR5UknYULOQfEiJx9Hc8p4khIll uc6xHdcN3fo4A7_iTske_RROS87ut7j5waYeGCgIDQRNSP7TlFAfD1_w_mlH rNPC_Ty.xC2s3NoNdS3zXomAbXSznw1_9.WZcu5w0AGs_xAVn3dH14NmGlmw wKlek3c6BVB_TtiBZ1XnQDXcvLve8hNMcwKs1cNfoRiF_67R_rKHakFEVmeS tRXknbJaNaUUTLacqnBs9aHUWLEyatrt1FmSLkhrPpkoGq3moaDPUn7s6ufg 9v2q053eeNxJlpGikgyJTDBIuA4t1O88wXqYmaFmIPuzp9I2TnqAEEniKYR_ tKUPpNbuO3GVam1vCRCpiJX5jyUtMl9UaVD.nr4UsoGYCJdBktR3DXhuHYvZ Duhl1yPj5lTr_gEaEPjFbDtyg6EWHTHvtjfhm56sWkNUYu4vCsof.j4v48zy pzaTI2jsZXXl1hRqidq.GtdzvDv6f_gOW_C.22PDbyWQs0jeM8Br7ArgW.Sy duv88Vcrzi0yfA9G_4Lt5zvOWBIXlf1iKA.79.SenJYfEGkhVKFHNuIsKVjL 2ug6c82MqQo3IQSuHXQLZdNbLtB.Oe4k5Y5nOhfbt1gg7Zo2u5OiPusNrrqY zUyyPCQqtB1LtBjXqHkzjMTf8FH5PO2_x76WE8VF5_JrlSKFPOqEQto6_kVr mzWqqSHV6gT_NWlbADx7G9hC7aGPanPVan7eAsRb4SRRaWbiuiMLv18Qd8dw 69x_V4kEeYLYkVmh4uUDWSVPS Received: from [24.130.37.147] by web2804.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 08:15:52 PDT X-Rocket-MIMEInfo: 002.001, R3V5cywKCklmIEkgbG9vayBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lYXJkbGV5LWxtYXAtdGVybWlub2xvZ3ktMDIsIEkgc2VlIHRoZSBkZWZpbml0aW9uIG9mIG1lYXN1cmVtZW50IHBlZXIgYXM6CgpNZWFzdXJlbWVudCBQZWVyOiBUaGUgZnVuY3Rpb24gdGhhdCByZWNlaXZlcyBjb250cm9sIG1lc3NhZ2VzIGFuZCB0ZXN0IHBhY2tldHMgZnJvbSBhIE1lYXN1cmVtZW50IEFnZW50IGFuZCBtYXkgcmVwbHkgdG8gdGhlCk1lYXN1cmVtZW50IEFnZW50IGFzIGRlZmluZWQgYnkgdGhlIE0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> Message-ID: <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 08:15:52 -0700 (PDT) From: Nalini Elkins To: "Aamer Akhter \(aakhter\)" , Juergen Schoenwaelder , "Bugenhagen, Michael K" In-Reply-To: <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MPnfe6TtGhvUds6Lfd2eiUIO00Y Cc: 'Brian Trammell' , "'lmap@ietf.org'" , 'Matt Mathis' , 'Dan Romascanu' Subject: Re: [lmap] One example of a "passive measurement peer" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:16:02 -0000 Guys,=0A=0AIf I look in http://tools.ietf.org/html/draft-eardley-lmap-termi= nology-02, I see the definition of measurement peer as:=0A=0AMeasurement Pe= er: The function that receives control messages and test packets from a Mea= surement Agent and may reply to the=0AMeasurement Agent as defined by the M= easurement Method. =0A=0AIs this correct?=0A=0ANow, imagine the following s= cenario in a hybrid measurement technique:=0A=0A1.=A0=A0In the MA, the hybr= id technique is to have the MA to append x bytes of diagnostic data to each= passive packet.=A0=A0For example, via a=A0command to the operating system.= =0A=0A2. =A0The MA resides in the client=0A=0A3. It would be ideal to have = the partner that the client is having the session with (let's call it "serv= er") also participate in this appending of x bytes of diagnostic data from = his side. =A0(Leaving aside for the moment the potential for this to be a D= oS vector. =A0That is a separate discussion).=A0=0A=0A4. =A0In this case, c= ould the MA not ask the "other end" to participate in extra data gathering?= =A0This would be a control message from an MA as defined above.=0A=0AWould= this be an example of a Measurement Peer in a hybrid scenario?=0A=0AI ask = because this is what we are thinking we may want to do.=0A=0AWhat am I miss= ing? =A0Is my understanding of this OK? =A0Please advise.=0A=0AThanks,=0A= =0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethest= ack.com=0A=0A=0A=0A________________________________=0AFrom: Aamer Akhter (a= akhter) =0ATo: Juergen Schoenwaelder ; "Bugenhagen, Michael K" =0ACc: 'Brian Trammell' ; 'Dan Romascanu' ; 'Matt Mathis' ; "'lmap@ietf.org'" =0ASent: Tuesday, March 11, 2014 8:03 AM=0ASubject: Re: [lmap= ] One example of a "passive measurement peer"=0A=0A=0AI agree on the remova= l of 'passive' in 'passive measurement peer' but if I remember correctly wh= ere was some discontent with just that as the solution. =0A=0ADo we have an= y clarity on where the discontent was coming from =0A=0A-----Original Messa= ge-----=0AFrom: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Sc= hoenwaelder=0ASent: Tuesday, March 11, 2014 10:59 AM=0ATo: Bugenhagen, Mich= ael K=0ACc: 'Brian Trammell'; 'lmap@ietf.org'; 'Matt Mathis'; 'Dan Romascan= u'=0ASubject: Re: [lmap] One example of a "passive measurement peer"=0A=0AH= i,=0A=0AI do not think we need the term 'passive measurement peer' in the f= ramework so perhaps the best thing is to not spent cycles trying to define = it.=0A=0A/js=0A=0AOn Tue, Mar 11, 2014 at 01:36:23PM +0000, Bugenhagen, Mic= hael K wrote:=0A> Just my 2 cents - but a word on future proofing... =0A> = =0A> The word passive is contextual...=0A> =0A> Which directly infers that = we should "contextualize" it buy saying "x" passive.=0A> As the technology = disturbers add new dimensions that also contain passive/active stuff this i= s going to get more confused....=0A> =0A> We're seriously having a problem = with this at NFV / Cloud technology SDO's where we've virtualized NIC's (Vn= ic's) and Vswitches both of which can be suspended (stopped)..=0A> =0A> It = may prove difficult to do passive measurements on a virtual x,y,z component= .=0A> Given Broadband Modems have this virtualized stuff, we should conside= r future proofing our terms.=0A> =0A> Summary - contextualizing passive may= be a great thing to future proof... for virtualization, those proof of con= cepts are in the works now.=0A> =0A> Cheers,=0A> Mike=0A> =0A> =0A> =0A> --= ---Original Message-----=0A> From: lmap [mailto:lmap-bounces@ietf.org] On B= ehalf Of Brian Trammell=0A> Sent: Tuesday, March 11, 2014 8:30 AM=0A> To: D= an Romascanu=0A> Cc: Matt Mathis; lmap@ietf.org=0A> Subject: Re: [lmap] One= example of a "passive measurement peer"=0A> =0A> hi Dan,=0A> =0A> Hm. I do= n't really consider this passive measurement -- we discussed this a bit in = the ippm registry design team, but I'm pretty sure there's a difference bet= ween (1) metrics derived from the operation of a protocol at one of the end= points participating in it and (2) metrics derived from the passive observa= tion of packets emitted by those protocols. I've always thought of passive = measurement as the latter, and (1) as something like "endpoint measurement"= , since metrics in (1) can also be derived from internal state at each endp= oint not synchronized over the protocol or otherwise hard to derive. =0A> = =0A> One could say that a midpath observation point (i.e. any observation p= oint other than an endpoint) has as many "passive peers" as there are obser= vable senders and recipients, while an "endpoint measurement agent" would h= ave a single "endpoint peer".=0A> =0A> (This becomes a much more interestin= g distinction as soon as you =0A> consider encrypting absolutely everything= you can, of course. At that =0A> point everything you're reduced to endpoi= nt measurement for everything =0A> other than the "envelope" and/or things = you derive through behavioral =0A> traffic analysis. But that's a separate = discussion, I think.)=0A> =0A> In any case, I stand by my statement that I'= d like to see peers defined _only_ as much as is absolutely necessary to ma= ke sense of the resulting control and reporting protocols.=0A> =0A> Cheers,= =0A> =0A> Brian=0A> =0A> =0A> On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan= ) wrote:=0A> =0A> > My other example of a 'passive man= agement peer' is an RTP peer which receives RTCP messages about the state o= f the other side of the connection and the parameters of the received traff= ic at the other end. All these are part of RTP/RTCP, there is no interactio= n between the controller and the MP, so I believe it can be considered pass= ive in LMAP terms.=0A> >=A0 =0A> > Regards,=0A> >=A0 =0A> > Dan=0A> >=A0 = =0A> >=A0 =0A> > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Mat= t Mathis=0A> > Sent: Friday, March 07, 2014 12:11 PM=0A> > To: lmap@ietf.or= g=0A> > Subject: [lmap] One example of a "passive measurement peer"=0A> >= =A0 =0A> > From the Internet Archive:=0A> >=A0 =0A> > http://web.archive.or= g/web/20071005130953/http://www-didc.lbl.gov/SC=0A> > NM/=0A> > =0A> > Than= ks,=0A> > --MM--=0A> > The best way to predict the future is to create it.= =A0 - Alan Kay=0A> > =0A> > Privacy matters!=A0 We know from recent events = that people are using our services to speak in defiance of unjust governmen= ts.=A0=A0=A0We treat privacy and security as matters of life and death, bec= ause for some users, they are.=0A> > ______________________________________= _________=0A> > lmap mailing list=0A> > lmap@ietf.org=0A> > https://www.iet= f.org/mailman/listinfo/lmap=0A> =0A> ______________________________________= _________=0A> lmap mailing list=0A> lmap@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/lmap=0A> =0A> ____________________________________________= ___=0A> lmap mailing list=0A> lmap@ietf.org=0A> https://www.ietf.org/mailma= n/listinfo/lmap=0A=0A-- =0AJuergen Schoenwaelder=A0 =A0 =A0 =A0 =A0=A0=A0Ja= cobs University Bremen gGmbH=0APhone: +49 421 200 3587=A0 =A0 =A0 =A0=A0=A0= Campus Ring 1, 28759 Bremen, Germany=0AFax:=A0=A0=A0+49 421 200 3103=A0 =A0= =A0 =A0=A0=A0=0A=0A_____________________= __________________________=0Almap mailing list=0Almap@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/lmap=0A=0A_____________________________________= __________=0Almap mailing list=0Almap@ietf.org=0Ahttps://www.ietf.org/mailm= an/listinfo/lmap=A0 From nobody Tue Mar 11 08:46:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8041A074D for ; Tue, 11 Mar 2014 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 pz-d3VZDWzim for ; Tue, 11 Mar 2014 08:46:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9435B1A047A for ; Tue, 11 Mar 2014 08:46:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C87572E; Tue, 11 Mar 2014 16:46:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5AaELQQmwVsW; Tue, 11 Mar 2014 16:46:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Mar 2014 16:46:18 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90A0320033; Tue, 11 Mar 2014 16:46:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yrvknWrMK8E0; Tue, 11 Mar 2014 16:46:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D335C2002F; Tue, 11 Mar 2014 16:46:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C6CBA2BB0179; Tue, 11 Mar 2014 16:46:14 +0100 (CET) Date: Tue, 11 Mar 2014 16:46:14 +0100 From: Juergen Schoenwaelder To: Nalini Elkins Message-ID: <20140311154614.GB78913@elstar.local> Mail-Followup-To: Nalini Elkins , "Aamer Akhter (aakhter)" , "Bugenhagen, Michael K" , 'Brian Trammell' , 'Dan Romascanu' , 'Matt Mathis' , "'lmap@ietf.org'" References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/a7prCKQyBgXi9x5419qkNYHMGdM Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 15:46:27 -0000 On Tue, Mar 11, 2014 at 08:15:52AM -0700, Nalini Elkins wrote: > Guys, > > If I look in http://tools.ietf.org/html/draft-eardley-lmap-terminology-02, I see the definition of measurement peer as: > > Measurement Peer: The function that receives control messages and test packets from a Measurement Agent and may reply to the > Measurement Agent as defined by the Measurement Method. > > Is this correct? Note that the terminology was moved into http://tools.ietf.org/html/draft-ietf-lmap-framework-03 and there is another udpate of this document pending... > Now, imagine the following scenario in a hybrid measurement technique: > > 1.  In the MA, the hybrid technique is to have the MA to append x bytes of diagnostic data to each passive packet.  For example, via a command to the operating system. > > 2.  The MA resides in the client > > 3. It would be ideal to have the partner that the client is having the session with (let's call it "server") also participate in this appending of x bytes of diagnostic data from his side.  (Leaving aside for the moment the potential for this to be a DoS vector.  That is a separate discussion).  > > 4.  In this case, could the MA not ask the "other end" to participate in extra data gathering?  This would be a control message from an MA as defined above. > > Would this be an example of a Measurement Peer in a hybrid scenario? > > I ask because this is what we are thinking we may want to do. > > What am I missing?  Is my understanding of this OK?  Please advise. Sure, an MA can have a control dialog with a remote MP. TWAMP and OWAMP would be examples of such control protocols. From an LMAP perspective, this interaction is out of scope of the LMAP protocol(s). /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 Mar 11 08:55:11 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27951A077D for ; Tue, 11 Mar 2014 08:55:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 edDqKEMZ3a-o for ; Tue, 11 Mar 2014 08:55:07 -0700 (PDT) Received: from nm5-vm6.access.bullet.mail.bf1.yahoo.com (nm5-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.133]) by ietfa.amsl.com (Postfix) with ESMTP id 72F911A076C for ; Tue, 11 Mar 2014 08:55:07 -0700 (PDT) Received: from [66.196.81.163] by nm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:55:01 -0000 Received: from [66.196.81.135] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:55:01 -0000 Received: from [127.0.0.1] by omp1011.access.mail.bf1.yahoo.com with NNFMP; 11 Mar 2014 15:55:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 556691.52389.bm@omp1011.access.mail.bf1.yahoo.com Received: (qmail 75351 invoked by uid 60001); 11 Mar 2014 15:55:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394553300; bh=wPUWtPhIjN/c5u0X3VViOcGoIInFgYAsz/PQhb6l5T0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uaCpehKLm5Ddy+r7Tw3HzI/iLFT5n+43Lnsp4kcRwa8Zayjyx0BaTXmkfYsizAXThISZ+6QN+o2HyvzGTyBJFI59LqMQgjN8yQXo6vgZ1TnqOJIfteY0fDm+JNGKw58aTofa3vYmBQ/4GtcDoj0y7fY4Rn10RzO0g6X2hh4MtK4= X-YMail-OSG: J6SrJxYVM1mxZSa2eANqN2ozlVhYHmb7H9wne6HcVO9Vcy4 Coq4hknYU4WVr1iEDSD6GiFhrLhJ88GxaviCPlgZHC1Ey3FsZKX6UzHuTCqr Bu_9ga21r0vvxZxCNBw5IZFxHZPvuOm_6q48WNtTGm_cuS1r_Bni3mC9G1V5 oAWE8GMmTq4Dcc2XhcS.x1ylgnGR6nBk6xkS8OIT6C1BjO4N4OWwbukYauIb rlRCQ1Jo5blY1You9PrwFGTg1QQJ2K7tkcUpq.FTMzyjMkP.ScSWt_c5LANu bjkEl1j3UNj9vGJWbgmhMgcxzNraMpmbdeXg0FGxrPd9pCueKFkauqIdHTIk NBj7Cip7iaOph1AVPfWqXGpR6EgQTRlW6xXk8YidsfiC1sG0U_d3x3tMuNSV MxTr6Joef4ODF92I5EGfpyDz8OF8GeOza92WnKp1h0cF4HNndxevMUdelD.C z6H2O7VHsSHYN9jLTxfPHkSrjKcDcsldOP3vZ.k.MNPhpYEDn5jnAcXWpl5x Fle4J7J_X1hLkzX.FzGf6y.lv5ZfJ030Rw_sX8ANNU1ozimiqnYtNOeXIZOn iRjccx9ZQqoGrOciVg9ZH6G3M8mV0lw0AH8J365vNyUTYCdBrDJbhwjPoUfc 9c.pxWrjeqi31J7pw6S0qTynFrP7KnPS9EOkzD2B8BYeB_.kreO4DrNTgUee iD7x4EEg240bXSWJlSaiX0d7Zyg21HTQtWmkVjQSi_1RwYg1NwtoiWx0- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 08:55:00 PDT X-Rocket-MIMEInfo: 002.001, SSB0aG91Z2h0IHRoZSBkaXNjdXNzaW9uIHdhcyBjb3VsZCB0aGVyZSBwb3NzaWJseSBiZSBhICJwYXNzaXZlIG1lYXN1cmVtZW50IHBlZXIiLgoKSWYgSSBhbSBub3QgbWlzdGFrZW4sIHRoZSBzY2VuYXJpbyBiZWxvdyB3b3VsZCBiZSBhICJoeWJyaWQgbWVhc3VyZW1lbnQgcGVlciIuCgpXaHkgd291bGQgdGhpcyBpbnRlcmFjdGlvbiBiZSBvdXQgb2Ygc2NvcGUgaWYgT1dBTVAgYW5kIFRXQU1QIGNvbnRyb2wgcHJvdG9jb2xzIGFyZSBpbiBzY29wZT8gwqDCoAoKwqAKVGhhbmtzLAoKTmFsaW5pIEVsa2lucwoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20140311154614.GB78913@elstar.local> Message-ID: <1394553300.79370.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 08:55:00 -0700 (PDT) From: Nalini Elkins To: Juergen Schoenwaelder In-Reply-To: <20140311154614.GB78913@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FPOUT2mN0oxxZe5-HTvqNDo48aE Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "passive measurement peer" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:55:10 -0000 I thought the discussion was could there possibly be a "passive measurement= peer".=0A=0AIf I am not mistaken, the scenario below would be a "hybrid me= asurement peer".=0A=0AWhy would this interaction be out of scope if OWAMP a= nd TWAMP control protocols are in scope? =A0=A0=0A=0A=A0=0AThanks,=0A=0ANal= ini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.co= m=0A=0A=0A=0A----- Original Message -----=0AFrom: Juergen Schoenwaelder =0ATo: Nalini Elkins =0ACc: Aamer Akhter (aakhter) ; "Bugenhag= en, Michael K" ; 'Brian Trammell' ; 'Dan Romascanu' ; 'Matt Mathis' ; "'lmap@ietf.org'" =0ASent: Tuesday, March= 11, 2014 8:46 AM=0ASubject: Re: [lmap] One example of a "passive measureme= nt peer"=0A=0AOn Tue, Mar 11, 2014 at 08:15:52AM -0700, Nalini Elkins wrote= :=0A> Guys,=0A> =0A> If I look in http://tools.ietf.org/html/draft-eardley-= lmap-terminology-02, I see the definition of measurement peer as:=0A> =0A> = Measurement Peer: The function that receives control messages and test pack= ets from a Measurement Agent and may reply to the=0A> Measurement Agent as = defined by the Measurement Method. =0A>=0A> Is this correct?=0A=0ANote that= the terminology was moved into=0A=0Ahttp://tools.ietf.org/html/draft-ietf-= lmap-framework-03=0A=0Aand there is another udpate of this document pending= ...=0A=0A> Now, imagine the following scenario in a hybrid measurement tech= nique:=0A> =0A> 1.=A0=A0In the MA, the hybrid technique is to have the MA t= o append x bytes of diagnostic data to each passive packet.=A0=A0For exampl= e, via a=A0command to the operating system.=0A> =0A> 2. =A0The MA resides i= n the client=0A> =0A> 3. It would be ideal to have the partner that the cli= ent is having the session with (let's call it "server") also participate in= this appending of x bytes of diagnostic data from his side. =A0(Leaving as= ide for the moment the potential for this to be a DoS vector. =A0That is a = separate discussion).=A0=0A> =0A> 4. =A0In this case, could the MA not ask = the "other end" to participate in extra data gathering? =A0This would be a = control message from an MA as defined above.=0A> =0A> Would this be an exam= ple of a Measurement Peer in a hybrid scenario?=0A> =0A> I ask because this= is what we are thinking we may want to do.=0A> =0A> What am I missing? =A0= Is my understanding of this OK? =A0Please advise.=0A=0ASure, an MA can have= a control dialog with a remote MP. TWAMP and=0AOWAMP would be examples of = such control protocols. From an LMAP=0Aperspective, this interaction is out= of scope of the LMAP protocol(s).=0A=0A/js=0A=0A-- =0AJuergen Schoenwaelde= r=A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH=0APhone: +49 421 200 3= 587=A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany=0AFax:=A0 +49 421= 200 3103=A0 =A0 =A0 =A0 =0A From nobody Tue Mar 11 09:06:00 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8A1A01AD for ; Tue, 11 Mar 2014 09:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 8bGyLma-FuKQ for ; Tue, 11 Mar 2014 09:05:55 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF61A046B for ; Tue, 11 Mar 2014 09:05:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFACk0H1OHCzIm/2dsb2JhbABagmUhO1fBN4EeFnSCJQEBAQEDAQEBDyg0CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIEQmHVwEMpS2rfxeOKzEHBoMegRQEmXeFQos5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,631,1389762000"; d="scan'208";a="52938811" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Mar 2014 12:05:45 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 11 Mar 2014 11:52:08 -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; Tue, 11 Mar 2014 17:05:43 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , Brian Trammell Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnwgAGCIoCAAAF9gIAAOJqA Date: Tue, 11 Mar 2014 16:05:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/crYn8AcrBbjACTCZDPikeO4r_Yg Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:05:58 -0000 Hi Al, You tried to explain by you did not convince me :-)=20 I do not see the remote RTP end-point as 'active'. There is nothing it does= differently (no 'activity') as the result of being a measurement peer.=20 However, I agree that removing 'active' from this document solves the dispu= te. If there is no 'active' there is no need to define 'passive'.=20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED > C (AL) > Sent: Tuesday, March 11, 2014 3:35 PM > To: Brian Trammell; Romascanu, Dan (Dan) > Cc: Matt Mathis; lmap@ietf.org > Subject: Re: [lmap] One example of a "passive measurement peer" >=20 > +1, I briefly tried to explain this to Dan in the back of the LMAP > meeting room (while the meeting was still in-progress, I think). >=20 > For me, it's a key distinction that the RTCP-reported end-point > measurements have a priori knowledge of the stream in RTP (like active), > while true passive measurements (at mid points) do not. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > > Sent: Tuesday, March 11, 2014 9:30 AM > > To: Dan Romascanu > > Cc: Matt Mathis; lmap@ietf.org > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > hi Dan, > > > > Hm. I don't really consider this passive measurement -- we discussed > > this a bit in the ippm registry design team, but I'm pretty sure > > there's a difference between (1) metrics derived from the operation of > > a protocol at one of the endpoints participating in it and (2) metrics > > derived from the passive observation of packets emitted by those > > protocols. I've always thought of passive measurement as the latter, > > and (1) as something like "endpoint measurement", since metrics in (1) > > can also be derived from internal state at each endpoint not > > synchronized over the protocol or otherwise hard to derive. > > > > One could say that a midpath observation point (i.e. any observation > > point other than an endpoint) has as many "passive peers" as there are > > observable senders and recipients, while an "endpoint measurement > agent" > > would have a single "endpoint peer". > > > > (This becomes a much more interesting distinction as soon as you > > consider encrypting absolutely everything you can, of course. At that > > point everything you're reduced to endpoint measurement for everything > > other than the "envelope" and/or things you derive through behavioral > > traffic analysis. But that's a separate discussion, I think.) > > > > In any case, I stand by my statement that I'd like to see peers > > defined _only_ as much as is absolutely necessary to make sense of the > > resulting control and reporting protocols. > > > > Cheers, > > > > Brian > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > wrote: > > > > > My other example of a 'passive management peer' is an RTP peer which > > receives RTCP messages about the state of the other side of the > > connection and the parameters of the received traffic at the other > > end. All these are part of RTP/RTCP, there is no interaction between > > the controller and the MP, so I believe it can be considered passive in= LMAP > terms. > > > > > > Regards, > > > > > > Dan > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > > Sent: Friday, March 07, 2014 12:11 PM > > > To: lmap@ietf.org > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > From the Internet Archive: > > > > > > http://web.archive.org/web/20071005130953/http://www- > didc.lbl.gov/SC > > > NM/ > > > > > > Thanks, > > > --MM-- > > > The best way to predict the future is to create it. - Alan Kay > > > > > > Privacy matters! We know from recent events that people are using > > > our > > services to speak in defiance of unjust governments. We treat privacy > > and security as matters of life and death, because for some users, > > they are. > > > _______________________________________________ > > > 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 09:06:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17811A046B for ; Tue, 11 Mar 2014 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 FDsgkpEBpu20 for ; Tue, 11 Mar 2014 09:06:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD2D1A01AD for ; Tue, 11 Mar 2014 09:06:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 62C361110; Tue, 11 Mar 2014 17:06:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nnurTr9ginfH; Tue, 11 Mar 2014 17:06:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Mar 2014 17:06:21 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5DF62002F; Tue, 11 Mar 2014 17:06:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 76i9pz7JZ0km; Tue, 11 Mar 2014 17:06:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C57C42002C; Tue, 11 Mar 2014 17:06:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE7FB2BB024A; Tue, 11 Mar 2014 17:06:19 +0100 (CET) Date: Tue, 11 Mar 2014 17:06:19 +0100 From: Juergen Schoenwaelder To: Nalini Elkins Message-ID: <20140311160619.GA79116@elstar.local> Mail-Followup-To: Nalini Elkins , "Aamer Akhter (aakhter)" , "Bugenhagen, Michael K" , 'Brian Trammell' , 'Dan Romascanu' , 'Matt Mathis' , "'lmap@ietf.org'" References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20140311154614.GB78913@elstar.local> <1394553300.79370.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1394553300.79370.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/q92HkfLA4q81-tA59L5BYTSF5Lg Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:06:30 -0000 On Tue, Mar 11, 2014 at 08:55:00AM -0700, Nalini Elkins wrote: > I thought the discussion was could there possibly be a "passive measurement peer". > > If I am not mistaken, the scenario below would be a "hybrid measurement peer". > > Why would this interaction be out of scope if OWAMP and TWAMP control protocols are in scope?    > OWAMP and TWAMP are not in scope of LMAP either. /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 Mar 11 09:14:02 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D241A0770 for ; Tue, 11 Mar 2014 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 fdeGlJQXozNe for ; Tue, 11 Mar 2014 09:13:59 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id DCFB71A0492 for ; Tue, 11 Mar 2014 09:13:58 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1463f135.2b5d9ac5d940.2496905.00-2411.6998089.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 11 Mar 2014 16:13:53 +0000 (UTC) X-MXL-Hash: 531f36415acf81da-2a73f19e80094fd7937ab77d6e46459ceec7669a Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 2263f135.0.2496335.00-2367.6996499.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 11 Mar 2014 16:13:23 +0000 (UTC) X-MXL-Hash: 531f36234fb38895-2f14c8da69a64814ffd71a07a6ff8c749c7dd061 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 s2BGDLwj008881; Tue, 11 Mar 2014 12:13:21 -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 s2BGDFSA008815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 12:13:17 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 11 Mar 2014 16:13:07 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 12:13:06 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "Aamer Akhter (aakhter)" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2CTfpYrhZBXkCbSLTC+QAK8pramTiAgAGR5YCAAAHfgIAAFyWAgAABQACAAAE0AP//zLYw Date: Tue, 11 Mar 2014 16:13:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303FD979@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <20140311150800.GA78913@elstar.local> In-Reply-To: <20140311150800.GA78913@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.215.133] 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=IZIwrxWa c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=1mO871IpWlkA:10 a=ofMgfj31e3cA:10 a=VsorbVFo2-IA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=TRUqD3WIQd_JbCBmFzQA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=EtOSQ06rQ2cmvlCJ:21 a=67U7lAD6jOZ-y6mx:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Pytt9HE37EvK3noTn5R3caz35NQ Cc: 'Brian Trammell' , "'lmap@ietf.org'" , 'Matt Mathis' , "Bugenhagen, Michael K" , 'Dan Romascanu' Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:14:01 -0000 > I do not recall having seen 'passive measurement peer' in the framework n= or > do I recall that it was suggested that this term be added. >=20 > At the meeting, we discussed to remove 'active' from a new proposed > definition of Measurement Agent (and I though we were slowly converging > to this change - but I am biased of course). >=20 > /js +1 What Phil proposed in the Friday meeting "Framework" slides (https://tools.= ietf.org/agenda/89/slides/slides-89-lmap-2.pdf) was=20 - Measurement Peer: A function assists a Measurement Agent with Active Meas= urement Tasks but has no Controller interface The proposal was to remove "Active" from this. There was lackluster humming= for and against which seems to have been due to needing better understandi= ng. I admit to also having needed better understanding. I think I understan= d much better now and am very much in favor of the proposal. Brian admitted to having led the opposition humming. I'm wondering if Brian= 's statement in this thread of > In any case, I stand by my statement that I'd like to see peers defined _= only_ as much as is absolutely necessary to make sense of the resulting con= trol and reporting protocols. might also indicate that we could get rid of "Active" in the proposed defin= ition and be done with it? Barbara From nobody Tue Mar 11 09:14:44 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6721A0499 for ; Tue, 11 Mar 2014 09:14: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 WP5yCa-jpYgm for ; Tue, 11 Mar 2014 09:14:41 -0700 (PDT) Received: from nm7.access.bullet.mail.gq1.yahoo.com (nm7.access.bullet.mail.gq1.yahoo.com [216.39.62.38]) by ietfa.amsl.com (Postfix) with ESMTP id 460721A0770 for ; Tue, 11 Mar 2014 09:14:41 -0700 (PDT) Received: from [216.39.60.166] by nm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Mar 2014 16:14:35 -0000 Received: from [216.39.60.248] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 11 Mar 2014 16:14:35 -0000 Received: from [127.0.0.1] by omp1019.access.mail.gq1.yahoo.com with NNFMP; 11 Mar 2014 16:14:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 620390.30351.bm@omp1019.access.mail.gq1.yahoo.com Received: (qmail 80346 invoked by uid 60001); 11 Mar 2014 16:14:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394554474; bh=pr2mIdm6vD30F4Hww5PjnmKZCr+W74OKqakqMACn0c4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bcpdg6W1A4CFTN8hKJcJ+APaJvXU+qTVlPgWz8ask8CURZSa/iCzzXcJs8zr/Lbug6qScMt+PMVs9pbqDQ4ynvIMwE0s4sglfggkYvvKrndGh/PkDTdGgvp64jMoPAc5UmPy2H7Frq4qw3lXxi+Mijs/PbZgJj9/wimu8UdMcQc= X-YMail-OSG: mo3rCoYVM1n3D4YNiIS77CMM_zb4EJvYLutALvFiW9fxmns V5KlBbG0QFwB7.HLh_IYPlLQzSY.UKksY1DUmV8j4mhCARrnqX2aVcHjWHfT KnlF0ku77NuaMrBMQFDg7ypN7f7JYYDrAGNGUfJ4YcczNf8n4DJ38jjrYWa3 idSShH3sULPh47ilXYJT7eV_8Lgdrj_Tc2PMCfyO.hr4gSmaFpNVpow4zdjT PwJ5_Db6ZsGkbq5EOhYt4WlO2PG_Y9UOThJVXyrGDFiaz9Qt_Lsi1uEeY1Nk sW03sPcuhdgNsBYYKFb4z7t37WI5Ex2Yls_jsbWWBfEnajwmoFve3DJvIguG u4sy1J68zAIq1nm7K.Zm5vAflRTwqMKNLFKB1k4_2NTC.tvzxLLQe8.KQqUu qDd1g6qB5bOWXCua3xQFHtI1SN9CdEw2VsS3f2uBPTskJ2uzWUtHToPtAsDu yJgwKPAeQRfbq8qjMyH86Fr4kACKf_CjLK6lxJpxQ0QSkA_MEy6r8JeVKfuD ugApKyGYreuVEPO71PBkD5u2zO5eNjlNYOyPP3DKoD0z_zPT6X20UwHdIKXk H8j..RKYwTEWvDbay_icW4l3Q_0MvByWjlu549ggTswUnb_I.Ltgu.mgWkvb .RdYajr2649raLtEFlyfXPNcVKEQu4L6f2SjeogbxBSuirCxNIpDyMdjCBb8 BT0bHwZcNjrYfpjORGVMJozY7AjopnM1LHBburALAlTIvLoRwhw-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Tue, 11 Mar 2014 09:14:34 PDT X-Rocket-MIMEInfo: 002.001, U29ycnksIGRpZCBub3QgdW5kZXJzdGFuZC4KClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uCsKgClRoYW5rcywKCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4KVG86IE5hbGluaSBFbGtpbnMgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2sBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20140311154614.GB78913@elstar.local> <1394553300.79370.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <20140311160619.GA79116@elstar.local> Message-ID: <1394554474.58650.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Tue, 11 Mar 2014 09:14:34 -0700 (PDT) From: Nalini Elkins To: Juergen Schoenwaelder In-Reply-To: <20140311160619.GA79116@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Dh7YsyUVL39n61epp4kbKC_Azf4 Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "passive measurement peer" X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:14:43 -0000 Sorry, did not understand.=0A=0AThanks for the clarification.=0A=A0=0AThank= s,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.inside= thestack.com=0A=0A=0A=0A----- Original Message -----=0AFrom: Juergen Schoen= waelder =0ATo: Nalini Elkins =0ACc: Aamer Akhter (aakhter) = ; "Bugenhagen, Michael K" ; 'Brian Tr= ammell' ; 'Dan Romascanu' ; 'Matt Mat= his' ; "'lmap@ietf.org'" =0ASent: Tue= sday, March 11, 2014 9:06 AM=0ASubject: Re: [lmap] One example of a "passiv= e measurement peer"=0A=0AOn Tue, Mar 11, 2014 at 08:55:00AM -0700, Nalini E= lkins wrote:=0A> I thought the discussion was could there possibly be a "pa= ssive measurement peer".=0A> =0A> If I am not mistaken, the scenario below = would be a "hybrid measurement peer".=0A> =0A> Why would this interaction b= e out of scope if OWAMP and TWAMP control protocols are in scope? =A0=A0=0A= > =0A=0AOWAMP and TWAMP are not in scope of LMAP either.=0A=0A/js=0A=0A-- = =0AJuergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH= =0APhone: +49 421 200 3587=A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Ger= many=0AFax:=A0 +49 421 200 3103=A0 =A0 =A0 =A0 =0A From nobody Tue Mar 11 09:16:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3911A0780 for ; Tue, 11 Mar 2014 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 dNgD8EceSFoo for ; Tue, 11 Mar 2014 09:16:29 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 27C111A0782 for ; Tue, 11 Mar 2014 09:16:29 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B2E3A0283; Tue, 11 Mar 2014 12:16:22 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 3B6DDA0282; Tue, 11 Mar 2014 12:16:22 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 12:16:21 -0400 From: Sharam Hakimi To: Juergen Schoenwaelder , "Nalini Elkins" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2A7LzZebZl1UqR7TUtS0elFpramTiAgAGR5YCAAAHfgIAAFyWAgAABQACAAANmAIAACHwAgAACcwCAAAMqgP//vokA Date: Tue, 11 Mar 2014 16:16:21 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B790AC@SPQCMBX02.exfo.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <20140311145912.GA78853@elstar.local> <75C0E47A1889264493A2DCB2869AC09633C7083F@xmb-rcd-x15.cisco.com> <1394550952.54174.YahooMailNeo@web2804.biz.mail.ne1.yahoo.com> <20140311154614.GB78913@elstar.local> <1394553300.79370.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> <20140311160619.GA79116@elstar.local> In-Reply-To: <20140311160619.GA79116@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20560.000 X-TM-AS-Result: No--14.526-5.0-31-10 X-imss-scan-details: No--14.526-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20560.000 X-TMASE-Result: 10--14.525700-5.000000 X-TMASE-MatchedRID: zGP2F0O7j/vZfnct5UBzcdxajlW+zwxCHtpQk3g8og5I8vAUEz0hfG5m ythqe+Bvm9ClOw0w1iL1ej67Eiww8WQkgVelQi418eSmTJSmEv0fXzVgO0hVqlpbYq2f4jz+1zP fwgjececf8Jg7NMHwdEzTJ4iSCN16yu5nkZfvbc2A/S4s4EQYUPnHCCDpOGOOM/dZg2GSzOWS+9 1twQWe63tHR4dyCCdDliXG6TWiBADTSS29OTRIaZ4CIKY/Hg3AhGBk0/7pshLEQdG7H66TyH4gK q42LRYk9T+hEMneLyHywOoCvREqMheqCQOlUjayTnja6lp2cJx+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/aw6RDlUlb30J8GXjpAUlRVRGI6g Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:16:31 -0000 I am still trying figure out what it means to have a passive measurement pe= er. The entire point of a passive measurement is to be transparent to the n= etwork, so how could something transparent have a peer. I believe the discussions were around not prohibiting passive measurements,= which I believe by definition will be transparent to the network. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Tuesday, March 11, 2014 12:06 PM To: Nalini Elkins Cc: 'lmap@ietf.org'; 'Dan Romascanu'; 'Matt Mathis'; 'Brian Trammell'; Aame= r Akhter (aakhter); Bugenhagen, Michael K Subject: Re: [lmap] One example of a "passive measurement peer" On Tue, Mar 11, 2014 at 08:55:00AM -0700, Nalini Elkins wrote: > I thought the discussion was could there possibly be a "passive measureme= nt peer". >=20 > If I am not mistaken, the scenario below would be a "hybrid measurement p= eer". >=20 > Why would this interaction be out of scope if OWAMP and TWAMP control pro= tocols are in scope? =A0=A0 >=20 OWAMP and TWAMP are not in scope of LMAP either. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 09:17:40 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392071A0799 for ; Tue, 11 Mar 2014 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od4mNdDRqZsU for ; Tue, 11 Mar 2014 09:17:25 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4051A07A0 for ; Tue, 11 Mar 2014 09:17:19 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 3DC345542BD; Tue, 11 Mar 2014 12:22:02 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id B798AEF85B; Tue, 11 Mar 2014 12:17:13 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 11 Mar 2014 12:17:13 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , Brian Trammell Date: Tue, 11 Mar 2014 12:17:12 -0400 Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnwgAGCIoCAAAF9gIAAOJqAgAADyIA= Message-ID: <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.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: http://mailarchive.ietf.org/arch/msg/lmap/ac5D5NlfbIKykJqkjLUyTGZ12Fw Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:17:33 -0000 Hi Dan, I don't see the RTP end-point as purely active of course, but not purely passive either, because of the measure of=20 knowledge of its streams and control over them (e.g., in response to RTCP reports, the stream characteristics=20 might be adjusted).=20 I think RTP end-points fit within the taxonomy of hybrid=20 (aspects which are both active & passive) techniques, like the IPv6 PDM, packet coloring, and others. Al > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, March 11, 2014 12:06 PM > To: MORTON, ALFRED C (AL); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Hi Al, >=20 > You tried to explain by you did not convince me :-) >=20 > I do not see the remote RTP end-point as 'active'. There is nothing it > does differently (no 'activity') as the result of being a measurement > peer. >=20 > However, I agree that removing 'active' from this document solves the > dispute. If there is no 'active' there is no need to define 'passive'. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED > > C (AL) > > Sent: Tuesday, March 11, 2014 3:35 PM > > To: Brian Trammell; Romascanu, Dan (Dan) > > Cc: Matt Mathis; lmap@ietf.org > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > +1, I briefly tried to explain this to Dan in the back of the LMAP > > meeting room (while the meeting was still in-progress, I think). > > > > For me, it's a key distinction that the RTCP-reported end-point > > measurements have a priori knowledge of the stream in RTP (like active)= , > > while true passive measurements (at mid points) do not. > > > > Al > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > To: Dan Romascanu > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > hi Dan, > > > > > > Hm. I don't really consider this passive measurement -- we discussed > > > this a bit in the ippm registry design team, but I'm pretty sure > > > there's a difference between (1) metrics derived from the operation o= f > > > a protocol at one of the endpoints participating in it and (2) metric= s > > > derived from the passive observation of packets emitted by those > > > protocols. I've always thought of passive measurement as the latter, > > > and (1) as something like "endpoint measurement", since metrics in (1= ) > > > can also be derived from internal state at each endpoint not > > > synchronized over the protocol or otherwise hard to derive. > > > > > > One could say that a midpath observation point (i.e. any observation > > > point other than an endpoint) has as many "passive peers" as there ar= e > > > observable senders and recipients, while an "endpoint measurement > > agent" > > > would have a single "endpoint peer". > > > > > > (This becomes a much more interesting distinction as soon as you > > > consider encrypting absolutely everything you can, of course. At that > > > point everything you're reduced to endpoint measurement for everythin= g > > > other than the "envelope" and/or things you derive through behavioral > > > traffic analysis. But that's a separate discussion, I think.) > > > > > > In any case, I stand by my statement that I'd like to see peers > > > defined _only_ as much as is absolutely necessary to make sense of th= e > > > resulting control and reporting protocols. > > > > > > Cheers, > > > > > > Brian > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > > wrote: > > > > > > > My other example of a 'passive management peer' is an RTP peer whic= h > > > receives RTCP messages about the state of the other side of the > > > connection and the parameters of the received traffic at the other > > > end. All these are part of RTP/RTCP, there is no interaction between > > > the controller and the MP, so I believe it can be considered passive > in LMAP > > terms. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt Mathis > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > To: lmap@ietf.org > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > From the Internet Archive: > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > didc.lbl.gov/SC > > > > NM/ > > > > > > > > Thanks, > > > > --MM-- > > > > The best way to predict the future is to create it. - Alan Kay > > > > > > > > Privacy matters! We know from recent events that people are using > > > > our > > > services to speak in defiance of unjust governments. We treat > privacy > > > and security as matters of life and death, because for some users, > > > they are. > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 09:23:09 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C751A0473 for ; Tue, 11 Mar 2014 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 x4pgyPr4shT0 for ; Tue, 11 Mar 2014 09:23:06 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF5FC1A046B for ; Tue, 11 Mar 2014 09:23:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMY3H1OHCzIm/2dsb2JhbABagmUhO1fBN4EeFnSCJQEBAQEDAQEBDyg0CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIEQmHVwEMpTOrfheOKzEHBoMegRQEmXeFQos5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,631,1389762000"; d="scan'208";a="53121384" 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; 11 Mar 2014 12:22:59 -0400 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; 11 Mar 2014 12:09:17 -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; Tue, 11 Mar 2014 17:22:52 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , Brian Trammell Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnwgAGCIoCAAAF9gIAAOJqAgAADyICAAAJssA== Date: Tue, 11 Mar 2014 16:22:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7s5lkb6j3vFciNC3-NOSSyyMDZc Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:23:08 -0000 Hi Al,=20 The behavior that you describe has nothing to do with LMAP. It belongs to t= he RTP protocol. No traffic is generated as a result of the fact that the r= emote endpoint is a peer.=20 Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, March 11, 2014 6:17 PM > To: Romascanu, Dan (Dan); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Hi Dan, >=20 > I don't see the RTP end-point as purely active of course, but not purely > passive either, because of the measure of knowledge of its streams and > control over them (e.g., in response to RTCP reports, the stream > characteristics might be adjusted). >=20 > I think RTP end-points fit within the taxonomy of hybrid (aspects which a= re > both active & passive) techniques, like the IPv6 PDM, packet coloring, an= d > others. >=20 > Al >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2014 12:06 PM > > To: MORTON, ALFRED C (AL); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Al, > > > > You tried to explain by you did not convince me :-) > > > > I do not see the remote RTP end-point as 'active'. There is nothing it > > does differently (no 'activity') as the result of being a measurement > > peer. > > > > However, I agree that removing 'active' from this document solves the > > dispute. If there is no 'active' there is no need to define 'passive'. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, > > > ALFRED C (AL) > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > +1, I briefly tried to explain this to Dan in the back of the LMAP > > > meeting room (while the meeting was still in-progress, I think). > > > > > > For me, it's a key distinction that the RTCP-reported end-point > > > measurements have a priori knowledge of the stream in RTP (like > > > active), while true passive measurements (at mid points) do not. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian > > > > Trammell > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > To: Dan Romascanu > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > hi Dan, > > > > > > > > Hm. I don't really consider this passive measurement -- we > > > > discussed this a bit in the ippm registry design team, but I'm > > > > pretty sure there's a difference between (1) metrics derived from > > > > the operation of a protocol at one of the endpoints participating > > > > in it and (2) metrics derived from the passive observation of > > > > packets emitted by those protocols. I've always thought of passive > > > > measurement as the latter, and (1) as something like "endpoint > > > > measurement", since metrics in (1) can also be derived from > > > > internal state at each endpoint not synchronized over the protocol = or > otherwise hard to derive. > > > > > > > > One could say that a midpath observation point (i.e. any > > > > observation point other than an endpoint) has as many "passive > > > > peers" as there are observable senders and recipients, while an > > > > "endpoint measurement > > > agent" > > > > would have a single "endpoint peer". > > > > > > > > (This becomes a much more interesting distinction as soon as you > > > > consider encrypting absolutely everything you can, of course. At > > > > that point everything you're reduced to endpoint measurement for > > > > everything other than the "envelope" and/or things you derive > > > > through behavioral traffic analysis. But that's a separate > > > > discussion, I think.) > > > > > > > > In any case, I stand by my statement that I'd like to see peers > > > > defined _only_ as much as is absolutely necessary to make sense of > > > > the resulting control and reporting protocols. > > > > > > > > Cheers, > > > > > > > > Brian > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > > > > > > > wrote: > > > > > > > > > My other example of a 'passive management peer' is an RTP peer > > > > > which > > > > receives RTCP messages about the state of the other side of the > > > > connection and the parameters of the received traffic at the other > > > > end. All these are part of RTP/RTCP, there is no interaction > > > > between the controller and the MP, so I believe it can be > > > > considered passive > > in LMAP > > > terms. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt > > > > > Mathis > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > To: lmap@ietf.org > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > From the Internet Archive: > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > didc.lbl.gov/SC > > > > > NM/ > > > > > > > > > > Thanks, > > > > > --MM-- > > > > > The best way to predict the future is to create it. - Alan Kay > > > > > > > > > > Privacy matters! We know from recent events that people are > > > > > using our > > > > services to speak in defiance of unjust governments. We treat > > privacy > > > > and security as matters of life and death, because for some users, > > > > they are. > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > _______________________________________________ > > > lmap mailing list > > > lmap@ietf.org > > > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 09:24:21 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F372F1A0773 for ; Tue, 11 Mar 2014 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 lMU2WxNSS0j0 for ; Tue, 11 Mar 2014 09:24:19 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED621A0736 for ; Tue, 11 Mar 2014 09:24:19 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ea83f135.2b3abe663940.1534454.00-2404.4066612.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 11 Mar 2014 16:24:14 +0000 (UTC) X-MXL-Hash: 531f38ae7f40f121-27fde37cd92f5e2582e7effd7fc02194fb52c176 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id ba83f135.0.1534429.00-2383.4066526.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 11 Mar 2014 16:24:13 +0000 (UTC) X-MXL-Hash: 531f38ad234f33a8-73dc54b3150a7e655ed4aff2243d59d1922c8d77 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 s2BGO9Ik018335; Tue, 11 Mar 2014 12:24:11 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2BGO2Ir018307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 12:24:03 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 11 Mar 2014 16:23:55 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 12:23:54 -0400 From: "STARK, BARBARA H" To: Sharam Hakimi , Juergen Schoenwaelder , Nalini Elkins Thread-Topic: [lmap] One example of a "measurement peer" that participates in passive measurements with a MA Thread-Index: Ac89Rkr/Ai2JkHPJRrWzoqtHfdRzKA== Date: Tue, 11 Mar 2014 16:23:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611303FD9E6@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.215.133] 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=LqUlPAhc c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=2W7FQQon5Q4A:10 a=ofMgfj31e3cA:10 a=VsorbVFo2-IA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=qwgUR72c8sxCFR6eW8oA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/25_x6Q3Sc0FdhLmr420otpaG-W4 Cc: "'lmap@ietf.org'" , 'Dan Romascanu' , 'Matt Mathis' , 'Brian Trammell' , "Aamer Akhter \(aakhter\)" , "Bugenhagen, Michael K" Subject: Re: [lmap] One example of a "measurement peer" that participates in passive measurements with a MA 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, 11 Mar 2014 16:24:21 -0000 > I am still trying figure out what it means to have a passive measurement > peer. The entire point of a passive measurement is to be transparent to t= he > network, so how could something transparent have a peer. >=20 > I believe the discussions were around not prohibiting passive measurement= s, > which I believe by definition will be transparent to the network. >=20 > Sharam I've changed the thread subject so people aren't confused by the thread sub= ject. There is no proposal to define anything called a "passive measurement peer"= . The term does not exist and is not proposed to exist.=20 There is no desire to prohibit or not prohibit passive measurements. It was, however, pointed out during Friday's meeting that a MP could be sen= ding traffic to a MA and the MA could be passively collecting measurement d= ata related to this traffic. Therefore, it was proposed to remove the word = "Active" from the proposed MP definition.=20 Barbara From nobody Tue Mar 11 09:42:58 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0621A074D for ; Tue, 11 Mar 2014 09:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC5yJwql0eTP for ; Tue, 11 Mar 2014 09:42:54 -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 196CD1A073F for ; Tue, 11 Mar 2014 09:42:53 -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 AF69812030F; Tue, 11 Mar 2014 12:47:23 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id CF5A5E2357; Tue, 11 Mar 2014 12:41:35 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Tue, 11 Mar 2014 12:42:46 -0400 From: "MORTON, ALFRED C (AL)" To: "Romascanu, Dan (Dan)" , Brian Trammell Date: Tue, 11 Mar 2014 12:42:18 -0400 Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnwgAGCIoCAAAF9gIAAOJqAgAADyICAAAJssIAAASkQ Message-ID: <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.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: http://mailarchive.ietf.org/arch/msg/lmap/5tt1YtA4dpAx0BHRBB3f-bcYA-4 Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:42:57 -0000 Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR metrics need to appear in the Registry (which is currently split into passive and active sub-registries), so that the LMAP Control and Collection protocols can refer to them. And this is an area where IPPM'ers seek LMAP'er comments. Al > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, March 11, 2014 12:23 PM > To: MORTON, ALFRED C (AL); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Hi Al, >=20 > The behavior that you describe has nothing to do with LMAP. It belongs to > the RTP protocol. No traffic is generated as a result of the fact that th= e > remote endpoint is a peer. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Tuesday, March 11, 2014 6:17 PM > > To: Romascanu, Dan (Dan); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Dan, > > > > I don't see the RTP end-point as purely active of course, but not purel= y > > passive either, because of the measure of knowledge of its streams and > > control over them (e.g., in response to RTCP reports, the stream > > characteristics might be adjusted). > > > > I think RTP end-points fit within the taxonomy of hybrid (aspects which > are > > both active & passive) techniques, like the IPv6 PDM, packet coloring, > and > > others. > > > > Al > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Tuesday, March 11, 2014 12:06 PM > > > To: MORTON, ALFRED C (AL); Brian Trammell > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > Hi Al, > > > > > > You tried to explain by you did not convince me :-) > > > > > > I do not see the remote RTP end-point as 'active'. There is nothing i= t > > > does differently (no 'activity') as the result of being a measuremen= t > > > peer. > > > > > > However, I agree that removing 'active' from this document solves the > > > dispute. If there is no 'active' there is no need to define 'passive'= . > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, > > > > ALFRED C (AL) > > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > +1, I briefly tried to explain this to Dan in the back of the LMAP > > > > meeting room (while the meeting was still in-progress, I think). > > > > > > > > For me, it's a key distinction that the RTCP-reported end-point > > > > measurements have a priori knowledge of the stream in RTP (like > > > > active), while true passive measurements (at mid points) do not. > > > > > > > > Al > > > > > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian > > > > > Trammell > > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > > To: Dan Romascanu > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > hi Dan, > > > > > > > > > > Hm. I don't really consider this passive measurement -- we > > > > > discussed this a bit in the ippm registry design team, but I'm > > > > > pretty sure there's a difference between (1) metrics derived from > > > > > the operation of a protocol at one of the endpoints participating > > > > > in it and (2) metrics derived from the passive observation of > > > > > packets emitted by those protocols. I've always thought of passiv= e > > > > > measurement as the latter, and (1) as something like "endpoint > > > > > measurement", since metrics in (1) can also be derived from > > > > > internal state at each endpoint not synchronized over the protoco= l > or > > otherwise hard to derive. > > > > > > > > > > One could say that a midpath observation point (i.e. any > > > > > observation point other than an endpoint) has as many "passive > > > > > peers" as there are observable senders and recipients, while an > > > > > "endpoint measurement > > > > agent" > > > > > would have a single "endpoint peer". > > > > > > > > > > (This becomes a much more interesting distinction as soon as you > > > > > consider encrypting absolutely everything you can, of course. At > > > > > that point everything you're reduced to endpoint measurement for > > > > > everything other than the "envelope" and/or things you derive > > > > > through behavioral traffic analysis. But that's a separate > > > > > discussion, I think.) > > > > > > > > > > In any case, I stand by my statement that I'd like to see peers > > > > > defined _only_ as much as is absolutely necessary to make sense o= f > > > > > the resulting control and reporting protocols. > > > > > > > > > > Cheers, > > > > > > > > > > Brian > > > > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > > > > > > > > > wrote: > > > > > > > > > > > My other example of a 'passive management peer' is an RTP peer > > > > > > which > > > > > receives RTCP messages about the state of the other side of the > > > > > connection and the parameters of the received traffic at the othe= r > > > > > end. All these are part of RTP/RTCP, there is no interaction > > > > > between the controller and the MP, so I believe it can be > > > > > considered passive > > > in LMAP > > > > terms. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt > > > > > > Mathis > > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > > To: lmap@ietf.org > > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > From the Internet Archive: > > > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > > didc.lbl.gov/SC > > > > > > NM/ > > > > > > > > > > > > Thanks, > > > > > > --MM-- > > > > > > The best way to predict the future is to create it. - Alan Kay > > > > > > > > > > > > Privacy matters! We know from recent events that people are > > > > > > using our > > > > > services to speak in defiance of unjust governments. We treat > > > privacy > > > > > and security as matters of life and death, because for some users= , > > > > > they are. > > > > > > _______________________________________________ > > > > > > lmap mailing list > > > > > > lmap@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > _______________________________________________ > > > > lmap mailing list > > > > lmap@ietf.org > > > > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 09:51:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EED1A07B8 for ; Tue, 11 Mar 2014 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 DBEPpMrL3tzk for ; Tue, 11 Mar 2014 09:51:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFFB1A07AF for ; Tue, 11 Mar 2014 09:51:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAK4+H1OHCzIm/2dsb2JhbABagmUhO1fBOIEeFnSCJQEBAQEDAQEBDyg0CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIEQmHVwEMpTirfReOKzEHBoMegRQEmXeFQos5gy2CKw X-IronPort-AV: E=Sophos;i="4.97,631,1389762000"; d="scan'208";a="52947171" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Mar 2014 12:51:08 -0400 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; 11 Mar 2014 12:37:31 -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; Tue, 11 Mar 2014 12:51:07 -0400 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , Brian Trammell Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2ER43E51CGNUCFZtXhPB4IXJraVSnwgAGCIoCAAAF9gIAAOJqAgAADyICAAAJssIAAASkQgAAFljA= Date: Tue, 11 Mar 2014 16:51:06 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5BV4xQFYM9OgUWuRJdSGYd_SfUg Cc: Matt Mathis , "lmap@ietf.org" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 16:51:30 -0000 OK - so maybe it is there (in IPPM) where 'active' and 'passive' need to be= defined. The criteria in my mind was whether traffic was generated beyond = the payload and control traffic that belongs to the protocols on the networ= k with the explicit purpose of executing a measurement procedure. I need ho= wever to read more on the IPPM context.=20 Regards,=20 Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, March 11, 2014 6:42 PM > To: Romascanu, Dan (Dan); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR metrics > need to appear in the Registry (which is currently split into passive and= active > sub-registries), so that the LMAP Control and Collection protocols can re= fer > to them. >=20 > And this is an area where IPPM'ers seek LMAP'er comments. > Al >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2014 12:23 PM > > To: MORTON, ALFRED C (AL); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Al, > > > > The behavior that you describe has nothing to do with LMAP. It belongs > > to the RTP protocol. No traffic is generated as a result of the fact > > that the remote endpoint is a peer. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, March 11, 2014 6:17 PM > > > To: Romascanu, Dan (Dan); Brian Trammell > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > Hi Dan, > > > > > > I don't see the RTP end-point as purely active of course, but not > > > purely passive either, because of the measure of knowledge of its > > > streams and control over them (e.g., in response to RTCP reports, > > > the stream characteristics might be adjusted). > > > > > > I think RTP end-points fit within the taxonomy of hybrid (aspects > > > which > > are > > > both active & passive) techniques, like the IPv6 PDM, packet > > > coloring, > > and > > > others. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Tuesday, March 11, 2014 12:06 PM > > > > To: MORTON, ALFRED C (AL); Brian Trammell > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > > > Hi Al, > > > > > > > > You tried to explain by you did not convince me :-) > > > > > > > > I do not see the remote RTP end-point as 'active'. There is > > > > nothing it does differently (no 'activity') as the result of being > > > > a measurement peer. > > > > > > > > However, I agree that removing 'active' from this document solves > > > > the dispute. If there is no 'active' there is no need to define 'pa= ssive'. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, > > > > > ALFRED C (AL) > > > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > +1, I briefly tried to explain this to Dan in the back of the > > > > > +LMAP > > > > > meeting room (while the meeting was still in-progress, I think). > > > > > > > > > > For me, it's a key distinction that the RTCP-reported end-point > > > > > measurements have a priori knowledge of the stream in RTP (like > > > > > active), while true passive measurements (at mid points) do not. > > > > > > > > > > Al > > > > > > > > > > > -----Original Message----- > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian > > > > > > Trammell > > > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > > > To: Dan Romascanu > > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > hi Dan, > > > > > > > > > > > > Hm. I don't really consider this passive measurement -- we > > > > > > discussed this a bit in the ippm registry design team, but I'm > > > > > > pretty sure there's a difference between (1) metrics derived > > > > > > from the operation of a protocol at one of the endpoints > > > > > > participating in it and (2) metrics derived from the passive > > > > > > observation of packets emitted by those protocols. I've always > > > > > > thought of passive measurement as the latter, and (1) as > > > > > > something like "endpoint measurement", since metrics in (1) > > > > > > can also be derived from internal state at each endpoint not > > > > > > synchronized over the protocol > > or > > > otherwise hard to derive. > > > > > > > > > > > > One could say that a midpath observation point (i.e. any > > > > > > observation point other than an endpoint) has as many "passive > > > > > > peers" as there are observable senders and recipients, while > > > > > > an "endpoint measurement > > > > > agent" > > > > > > would have a single "endpoint peer". > > > > > > > > > > > > (This becomes a much more interesting distinction as soon as > > > > > > you consider encrypting absolutely everything you can, of > > > > > > course. At that point everything you're reduced to endpoint > > > > > > measurement for everything other than the "envelope" and/or > > > > > > things you derive through behavioral traffic analysis. But > > > > > > that's a separate discussion, I think.) > > > > > > > > > > > > In any case, I stand by my statement that I'd like to see > > > > > > peers defined _only_ as much as is absolutely necessary to > > > > > > make sense of the resulting control and reporting protocols. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) > > > > > > > > > > > wrote: > > > > > > > > > > > > > My other example of a 'passive management peer' is an RTP > > > > > > > peer which > > > > > > receives RTCP messages about the state of the other side of > > > > > > the connection and the parameters of the received traffic at > > > > > > the other end. All these are part of RTP/RTCP, there is no > > > > > > interaction between the controller and the MP, so I believe it > > > > > > can be considered passive > > > > in LMAP > > > > > terms. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt > > > > > > > Mathis > > > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > > > To: lmap@ietf.org > > > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > > > From the Internet Archive: > > > > > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > > > didc.lbl.gov/SC > > > > > > > NM/ > > > > > > > > > > > > > > Thanks, > > > > > > > --MM-- > > > > > > > The best way to predict the future is to create it. - Alan > > > > > > > Kay > > > > > > > > > > > > > > Privacy matters! We know from recent events that people are > > > > > > > using our > > > > > > services to speak in defiance of unjust governments. We treat > > > > privacy > > > > > > and security as matters of life and death, because for some > > > > > > users, they are. > > > > > > > _______________________________________________ > > > > > > > lmap mailing list > > > > > > > lmap@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > _______________________________________________ > > > > > > lmap mailing list > > > > > > lmap@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 10:14:46 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DFA1A0767 for ; Tue, 11 Mar 2014 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6] 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 dJetFF9hRtOq for ; Tue, 11 Mar 2014 10:14:40 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F61A074F for ; Tue, 11 Mar 2014 10:14:40 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2BHEU4Z008633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 11:14:31 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BB57C1E006C; Tue, 11 Mar 2014 11:14:25 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 801A01E0060; Tue, 11 Mar 2014 11:14:25 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHEOG3025477; Tue, 11 Mar 2014 12:14:24 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHEOg5025424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 12:14:24 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 12:14:23 -0500 From: "Bugenhagen, Michael K" To: "'Romascanu, Dan (Dan)'" , "'MORTON, ALFRED C (AL)'" , "'Brian Trammell'" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2Ay6PnPFJo/0eeoDd4KhTzipraqfuAgAGR5YCAAAF+gIAAKhkAgAADNwCAAAGUgIAABW8AgAACdgD//7DUsA== Date: Tue, 11 Mar 2014 17:14:22 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/rbp3G199Ls2cGpIu9ITE8HxSm8A Cc: 'Matt Mathis' , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 17:14:43 -0000 Here's what I meant by contextualization of the "verb" passive... Passive means "not to react" to something..(if we're sticking to Webster's = definition) So contextually a=20 1) Passive test - means the test of the subject would not react - so the se= rvice resources, and service flow are NOT impacted 2) Passive peer (should not exist.. because it wouldn't react ? ... right=20 I think the real issue here is that we're talking about the different layer= reactors (server entities)=20 That are in a protocol like Ping, OWAMP, TWAMP, ...=20 Vs. A LMAP probe "server function"=20 You could have a test that is passive to a LMAP probe level, but Active at = a lower protocol level. This is why we introduced a hierarchy like this on the BBF side. Suggestion to un wrinkle this-- 1) Describe the probe agent layer terms Protocol based Measurement agent (distributed control / self contained con= trol) Vs. LMAP based MA -=20 Then Active / Passive starts making sense again. Regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, March 11, 2014 11:51 AM To: MORTON, ALFRED C (AL); Brian Trammell Cc: Matt Mathis; lmap@ietf.org Subject: Re: [lmap] One example of a "passive measurement peer" OK - so maybe it is there (in IPPM) where 'active' and 'passive' need to be= defined. The criteria in my mind was whether traffic was generated beyond = the payload and control traffic that belongs to the protocols on the networ= k with the explicit purpose of executing a measurement procedure. I need ho= wever to read more on the IPPM context.=20 Regards,=20 Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, March 11, 2014 6:42 PM > To: Romascanu, Dan (Dan); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR=20 > metrics need to appear in the Registry (which is currently split into=20 > passive and active sub-registries), so that the LMAP Control and=20 > Collection protocols can refer to them. >=20 > And this is an area where IPPM'ers seek LMAP'er comments. > Al >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2014 12:23 PM > > To: MORTON, ALFRED C (AL); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Al, > > > > The behavior that you describe has nothing to do with LMAP. It=20 > > belongs to the RTP protocol. No traffic is generated as a result of=20 > > the fact that the remote endpoint is a peer. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, March 11, 2014 6:17 PM > > > To: Romascanu, Dan (Dan); Brian Trammell > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > Hi Dan, > > > > > > I don't see the RTP end-point as purely active of course, but not=20 > > > purely passive either, because of the measure of knowledge of its=20 > > > streams and control over them (e.g., in response to RTCP reports,=20 > > > the stream characteristics might be adjusted). > > > > > > I think RTP end-points fit within the taxonomy of hybrid (aspects=20 > > > which > > are > > > both active & passive) techniques, like the IPv6 PDM, packet=20 > > > coloring, > > and > > > others. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Tuesday, March 11, 2014 12:06 PM > > > > To: MORTON, ALFRED C (AL); Brian Trammell > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > > > Hi Al, > > > > > > > > You tried to explain by you did not convince me :-) > > > > > > > > I do not see the remote RTP end-point as 'active'. There is=20 > > > > nothing it does differently (no 'activity') as the result of=20 > > > > being a measurement peer. > > > > > > > > However, I agree that removing 'active' from this document=20 > > > > solves the dispute. If there is no 'active' there is no need to def= ine 'passive'. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON,=20 > > > > > ALFRED C (AL) > > > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > +1, I briefly tried to explain this to Dan in the back of the=20 > > > > > +LMAP > > > > > meeting room (while the meeting was still in-progress, I think). > > > > > > > > > > For me, it's a key distinction that the RTCP-reported=20 > > > > > end-point measurements have a priori knowledge of the stream=20 > > > > > in RTP (like active), while true passive measurements (at mid poi= nts) do not. > > > > > > > > > > Al > > > > > > > > > > > -----Original Message----- > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian=20 > > > > > > Trammell > > > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > > > To: Dan Romascanu > > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > hi Dan, > > > > > > > > > > > > Hm. I don't really consider this passive measurement -- we=20 > > > > > > discussed this a bit in the ippm registry design team, but=20 > > > > > > I'm pretty sure there's a difference between (1) metrics=20 > > > > > > derived from the operation of a protocol at one of the=20 > > > > > > endpoints participating in it and (2) metrics derived from=20 > > > > > > the passive observation of packets emitted by those=20 > > > > > > protocols. I've always thought of passive measurement as the=20 > > > > > > latter, and (1) as something like "endpoint measurement",=20 > > > > > > since metrics in (1) can also be derived from internal state=20 > > > > > > at each endpoint not synchronized over the protocol > > or > > > otherwise hard to derive. > > > > > > > > > > > > One could say that a midpath observation point (i.e. any=20 > > > > > > observation point other than an endpoint) has as many=20 > > > > > > "passive peers" as there are observable senders and=20 > > > > > > recipients, while an "endpoint measurement > > > > > agent" > > > > > > would have a single "endpoint peer". > > > > > > > > > > > > (This becomes a much more interesting distinction as soon as=20 > > > > > > you consider encrypting absolutely everything you can, of=20 > > > > > > course. At that point everything you're reduced to endpoint=20 > > > > > > measurement for everything other than the "envelope" and/or=20 > > > > > > things you derive through behavioral traffic analysis. But=20 > > > > > > that's a separate discussion, I think.) > > > > > > > > > > > > In any case, I stand by my statement that I'd like to see=20 > > > > > > peers defined _only_ as much as is absolutely necessary to=20 > > > > > > make sense of the resulting control and reporting protocols. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan)=20 > > > > > > > > > > > wrote: > > > > > > > > > > > > > My other example of a 'passive management peer' is an RTP=20 > > > > > > > peer which > > > > > > receives RTCP messages about the state of the other side of=20 > > > > > > the connection and the parameters of the received traffic at=20 > > > > > > the other end. All these are part of RTP/RTCP, there is no=20 > > > > > > interaction between the controller and the MP, so I believe=20 > > > > > > it can be considered passive > > > > in LMAP > > > > > terms. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of=20 > > > > > > > Matt Mathis > > > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > > > To: lmap@ietf.org > > > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > > > From the Internet Archive: > > > > > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > > > didc.lbl.gov/SC > > > > > > > NM/ > > > > > > > > > > > > > > Thanks, > > > > > > > --MM-- > > > > > > > The best way to predict the future is to create it. -=20 > > > > > > > Alan Kay > > > > > > > > > > > > > > Privacy matters! We know from recent events that people=20 > > > > > > > are using our > > > > > > services to speak in defiance of unjust governments. We treat > > > > privacy > > > > > > and security as matters of life and death, because for some=20 > > > > > > users, they are. > > > > > > > _______________________________________________ > > > > > > > lmap mailing list > > > > > > > lmap@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > _______________________________________________ > > > > > > lmap mailing list > > > > > > lmap@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 10:15:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DD1A0767 for ; Tue, 11 Mar 2014 10:15:39 -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 XLT-jEkb2TC2 for ; Tue, 11 Mar 2014 10:15:37 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0868D1A074F for ; Tue, 11 Mar 2014 10:15:36 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s2BHFUpY023618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Mar 2014 12:15:30 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 18CC41E006C for ; Tue, 11 Mar 2014 11:15:25 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id ADBDA1E0053 for ; Tue, 11 Mar 2014 11:15:24 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHFNVi000245 for ; Tue, 11 Mar 2014 12:15:23 -0500 (CDT) Received: from [10.188.208.192] (x1069818.dhcp.intranet [10.188.208.192]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHFJhK000111; Tue, 11 Mar 2014 12:15:20 -0500 (CDT) Message-ID: <531F44A7.8010604@centurylink.com> Date: Tue, 11 Mar 2014 11:15:19 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> In-Reply-To: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------010805090302010505010507" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ByekdFOlNgdWGVdp4fQUJ12HtNw Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:15:39 -0000 This is a multi-part message in MIME format. --------------010805090302010505010507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I finally got around to reviewing the Information Model. Attached are my comments. In summary: It appears that the Information Channel is being referenced with Pre-configuration information rather than Configuration information. Pre-configuration information cannot be provided via the Information Channel because the MA has to register with the Controller before it can receive Configuration information from the Controller. There is a reference that Measurement Tasks will be executed "in order" which may imply "serially" to some. It would be more accurate to say executed per the Measurement Schedule. At one time I thought I heard that one of the "Elements" may be split into two Elements. If that happens, the draft will need to be updated. Given the recent discussion on Active vs Passive, maybe that is no longer under consideration. Regarding Operational Update messages, consideration should be given to a "Scheduling conflict" message. This may also need to be mentioned in Section 3.7 "Reporting Information". There were also a few editorial items. Overall, it is looking good. Charles On 2/16/2014 8:20 AM, internet-drafts@ietf.org wrote: > 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-00.txt > Pages : 21 > Date : 2014-02-14 > > 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-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/ > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com --------------010805090302010505010507 Content-Type: application/msword; name="draft-ietf-lmap-information-model-00cc.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-lmap-information-model-00cc.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAzAAAAAAA AAAAEAAAzgAAAAEAAAD+////AAAAAMoAAADLAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEABYAJBAAA8BK/AAAAAAAAEAAAAAAACAAA Ob4AAA4AYmpialfZV9kAAAAAAAAAAAAAAAAAAAAAAAAJBBYANBwBADWzAQA1swEAy7AAAAAA AAAAAAAAAAAAAG0FAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAALcAAAAAAAYIAAAAAAAABggAAEkVAAAAAAAASRUAAAAAAABzFQAA NgEAAEsXAAAsAAAAdxcAABQAAAAAAAAAAAAAAP////8AAAAAixcAAAAAAACLFwAAAAAAAIsX AAAAAAAAixcAACQAAACvFwAAVAEAAIsXAAAAAAAAdj8AABwCAAADGQAAAAAAAAMZAAAAAAAA AxkAAAAAAAADGQAAAAAAAAMZAAAAAAAA3hkAAAAAAADeGQAAAAAAAN4ZAAAAAAAAvz4AAAIA AADBPgAAAAAAAME+AAAAAAAAwT4AAAAAAADBPgAAAAAAAME+AAAAAAAAwT4AACQAAACSQQAA ogIAADREAAB6AAAA5T4AABUAAAAAAAAAAAAAAAAAAAAAAAAASRUAACoAAADeGQAAZgAAAAAA AAAAAAAAAAAAAAAAAADeGQAAAAAAAN4ZAAAAAAAARBoAAEQAAACIGgAAJAAAAOU+AAAAAAAA AAAAAAAAAABJFQAAAAAAAEkVAAAAAAAAAxkAAAAAAAAAAAAAAAAAAAMZAADbAAAA+j4AAEAA AABSOwAAAAAAAFI7AAAAAAAAUjsAAAAAAACsGgAAxAYAAEkVAAAAAAAAAxkAAAAAAABJFQAA AAAAAAMZAAAAAAAAvz4AAAAAAAAAAAAAAAAAAFI7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3hkAAAAAAAC/PgAAAAAAAAAAAAAAAAAA UjsAAAAAAABSOwAAHgAAAOc9AAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMz4AAAAAAAADGQAA AAAAAP////8AAAAAUOS+sks9zwEAAAAAAAAAAIsXAAAAAAAAcCEAAGQYAAD/PQAACAAAAAAA AAAAAAAAqz4AABQAAAA6PwAAPAAAAHY/AAAAAAAABz4AACwAAACuRAAAAAAAANQ5AAB+AQAA rkQAABAAAAAzPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK5EAAAAAAAAAAAAAAAAAACpFgAA ogAAADM+AAB4AAAA3hkAAAAAAADeGQAAAAAAAFI7AAAAAAAA3hkAAAAAAADeGQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3hkAAAAAAADeGQAAAAAAAN4ZAAAAAAAA 5T4AAAAAAADlPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUjsAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN4ZAAAAAAAA3hkAAAAAAADeGQAA AAAAAHY/AAAAAAAA3hkAAAAAAADeGQAAAAAAAN4ZAAAAAAAA3hkAAAAAAAAAAAAAAAAAAP// //8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAA AAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAK5EAAAAAAAA3hkAAAAAAADeGQAA AAAAAN4ZAAAAAAAA3hkAAAAAAADeGQAAAAAAAN4ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADeGQAAAAAAAN4ZAAAAAAAA 3hkAAAAAAAAGCAAACQwAAA8UAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gQnVyYnJpZGdlDUludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4g RWFyZGxleQ1JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAg ICAgICAgICAgICBCcml0aXNoIFRlbGVjb20NRXhwaXJlczogQXVndXN0IDE4LCAyMDE0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBCYWdudWxvDSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVbml2ZXJzaWRhZCBDYXJsb3MgSUlJ IGRlIE1hZHJpZA0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEouIFNjaG9lbndhZWxkZXINICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJy dWFyeSAxNCwgMjAxNA0NDSAgICAgSW5mb3JtYXRpb24gTW9kZWwgZm9yIExhcmdlLVNjYWxl IE1lYXN1cmVtZW50IFBsYXRmb3JtcyAoTE1BUCkNICAgICAgICAgICAgICAgICAgZHJhZnQt aWV0Zi1sbWFwLWluZm9ybWF0aW9uLW1vZGVsLTAwDQ1BYnN0cmFjdA0NICAgVGhpcyBJbmZv cm1hdGlvbiBNb2RlbCBhcHBsaWVzIHRvIHRoZSBNZWFzdXJlbWVudCBBZ2VudCB3aXRoaW4g YQ0gICBMYXJnZS1TY2FsZSBNZWFzdXJlbWVudCBQbGF0Zm9ybS4gIEFzIHN1Y2ggaXQgb3V0 bGluZXMgdGhlDSAgIGluZm9ybWF0aW9uIHRoYXQgaXMgKHByZS0pY29uZmlndXJlZCBvbiB0 aGUgTUEgb3IgZXhpc3RzIGluDSAgIGNvbW11bmljYXRpb25zIHdpdGggYSBDb250cm9sbGVy IG9yIENvbGxlY3RvciB3aXRoaW4gYW4gTE1BUA0gICBmcmFtZXdvcmsuICBUaGUgcHVycG9z ZSBvZiBzdWNoIGFuIEluZm9ybWF0aW9uIE1vZGVsIGlzIHRvIHByb3ZpZGUgYQ0gICBwcm90 b2NvbCBhbmQgZGV2aWNlIGluZGVwZW5kZW50IHZpZXcgb2YgdGhlIE1BIHRoYXQgY2FuIGJl DSAgIGltcGxlbWVudGVkIHZpYSBvbmUgb3IgbW9yZSBDb250cm9sIGFuZCBSZXBvcnQgcHJv dG9jb2xzLg0NUmVxdWlyZW1lbnRzIExhbmd1YWdlDQ0gICBUaGUga2V5IHdvcmRzICJNVVNU IiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDSAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDSAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLg0NU3RhdHVzIG9mIHRoaXMgTWVtbw0NICAg VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZQ0gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0NICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUNICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NICAgRHJhZnRzIGlzIGF0IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQ0gICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp eCBtb250aHMNICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0NICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBBdWd1c3QgMTgsIDIwMTQuDQ1Db3B5 cmlnaHQgTm90aWNlDQ0NDQ1CdXJicmlkZ2UsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMTgsIDIwMTQgICAgICAgICAgICAgICAgW1BhZ2UgMV0NDA1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCAgICAgICAgICAgIEZlYnJ1YXJ5IDIw MTQNDQ0gICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMg aWRlbnRpZmllZCBhcyB0aGUNICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQ0gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUg SUVURiBUcnVzdCdzIExlZ2FsDSAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMNICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mDSAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVz Y3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNICAgdG8g dGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRv Y3VtZW50IG11c3QNICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDSAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNp b25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0gICBkZXNjcmliZWQg aW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAg IDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMw0gICAyLiAgTm90YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNICAgMy4gIExNQVAgSW5mb3Jt YXRpb24gTW9kZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0 DSAgICAgMy4xLiAgSW5mb3JtYXRpb24gU3RydWN0dXJlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNA0gICAgIDMuMi4gIFByZS1Db25maWd1cmF0aW9uIEluZm9y bWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNICAgICAzLjMuICBDb25m aWd1cmF0aW9uIEluZm9ybWF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2DSAgICAgMy40LiAgSW5zdHJ1Y3Rpb24gSW5mb3JtYXRpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0gICAgIDMuNS4gIE1BIHRvIENvbnRyb2xsZXIgSW5m b3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENICAgICAzLjYuICBD YXBhYmlsaXR5IGFuZCBTdGF0dXMgSW5mb3JtYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEzDSAgICAgMy43LiAgUmVwb3J0aW5nIEluZm9ybWF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0gICAgIDMuOC4gIENoYW5uZWxzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNICAgICAzLjku ICBUaW1pbmcgSW5mb3JtYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE2DSAgICAgICAzLjkuMS4gIFBlcmlvZGljIFRpbWluZyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0gICAgICAgMy45LjIuICBDYWxlbmRhciBU aW1pbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNICAgICAg IDMuOS4zLiAgT25lLU9mZiBUaW1pbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE4DSAgICAgICAzLjkuNC4gIEltbWVkaWF0ZSBUaW1pbmcgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0gICAgICAgMy45LjUuICBUaW1pbmcg UmFuZG9tbmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNICAg NC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE5DSAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0gICA2LiAgQWNrbm93bGVkZ2Vt ZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkN ICAgNy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDIwDSAgICAgNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0gICAgIDcuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjANICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIwDQ0NDQ0NDQ0NDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAg ICAgIEV4cGlyZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQwN SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAg ICAgICBGZWJydWFyeSAyMDE0DQ0NMS4gIEludHJvZHVjdGlvbg0NICAgQSBsYXJnZS1zY2Fs ZSBtZWFzdXJlbWVudCBwbGF0Zm9ybSBpcyBhIGNvbGxlY3Rpb24gb2YgY29tcG9uZW50cyB0 aGF0DSAgIHdvcmsgaW4gYSBjb29yZGluYXRlZCBmYXNoaW9uIHRvIHBlcmZvcm0gbWVhc3Vy ZW1lbnRzIGZyb20gYSBsYXJnZQ0gICBudW1iZXIgb2YgdmFudGFnZSBwb2ludHMuICBUaGUg bWFpbiBjb21wb25lbnRzIG9mIGEgbGFyZ2Utc2NhbGUNICAgbWVhc3VyZW1lbnQgcGxhdGZv cm0gYXJlIHRoZSBNZWFzdXJlbWVudCBBZ2VudHMgKGhlcmVhZnRlciBNQXMpLCB0aGUNICAg Q29udHJvbGxlcihzKSBhbmQgdGhlIENvbGxlY3RvcihzKS4NDSAgIFRoZSBNQXMgYXJlIHRo ZSBlbGVtZW50cyBhY3R1YWxseSBwZXJmb3JtaW5nIHRoZSBtZWFzdXJlbWVudHMuICBUaGUN ICAgTUFzIGFyZSBjb250cm9sbGVkIGJ5IGV4YWN0bHkgb25lIENvbnRyb2xsZXIgYXQgYSB0 aW1lIGFuZCB0aGUNICAgQ29sbGVjdG9ycyBnYXRoZXIgdGhlIHJlc3VsdHMgZ2VuZXJhdGVk IGJ5IHRoZSBNQXMuICBJbiBhIG51dHNoZWxsLA0gICB0aGUgbm9ybWFsIG9wZXJhdGlvbiBv ZiBhIGxhcmdlLXNjYWxlIG1lYXN1cmVtZW50IHBsYXRmb3JtIHN0YXJ0cw0gICB3aXRoIHRo ZSBDb250cm9sbGVyIGluc3RydWN0aW5nIGEgc2V0IG9mIG9uZSBvciBtb3JlIE1BcyB0byBw ZXJmb3JtIGENICAgc2V0IG9mIG9uZSBvciBtb3JlIE1lYXN1cmVtZW50IFRhc2tzIGF0IGEg Y2VydGFpbiBwb2ludCBpbiB0aW1lLiAgVGhlDSAgIE1BcyBleGVjdXRlIHRoZSBpbnN0cnVj dGlvbnMgZnJvbSBhIENvbnRyb2xsZXIsIGFuZCBvbmNlIHRoZXkgaGF2ZQ0gICBkb25lIHNv LCB0aGV5IHJlcG9ydCB0aGUgcmVzdWx0cyBvZiB0aGUgbWVhc3VyZW1lbnRzIHRvIG9uZSBv ciBtb3JlDSAgIENvbGxlY3RvcnMuICBUaGUgb3ZlcmFsbCBmcmFtZXdvcmsgZm9yIGEgTGFy Z2UgTWVhc3VyZW1lbnQgcGxhdGZvcm0NICAgYXMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IGlz IGRlc2NyaWJlZCBpbiBkZXRhaWwgaW4NICAgW0ktRC5pZXRmLWxtYXAtZnJhbWV3b3JrXS4N DSAgIEEgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQgcGxhdGZvcm0gaW52b2x2ZXMgYmFzaWNh bGx5IHRocmVlDSAgIHByb3RvY29scywgbmFtZWx5LCBhIENvbnRyb2wgcHJvdG9jb2wgYmV0 d2VlbiBhIENvbnRyb2xsZXIgYW5kIHRoZQ0gICBNQXMsIGEgUmVwb3J0IHByb3RvY29sIGJl dHdlZW4gdGhlIE1BcyBhbmQgdGhlIENvbGxlY3RvcihzKSBhbmQNICAgc2V2ZXJhbCBtZWFz dXJlbWVudCBwcm90b2NvbHMgYmV0d2VlbiB0aGUgTUFzIGFuZCBNZWFzdXJlbWVudCBQZWVy cw0gICAoTVBzKSwgdXNlZCB0byBhY3R1YWxseSBwZXJmb3JtIHRoZSBtZWFzdXJlbWVudHMu ICBJbiBhZGRpdGlvbiBzb21lDSAgIGluZm9ybWF0aW9uIGlzIHJlcXVpcmVkIHRvIGJlIHBy b3Zpc2lvbmVkIGluIHRoZSBNQSBwcmlvciB0byBhbnkNICAgY29tbXVuaWNhdGlvbiB3aXRo IHRoZSBpbml0aWFsIENvbnRyb2xsZXIuDQ0gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IGluZm9ybWF0aW9uIG1vZGVsIGZvciBib3RoIHRoZSBDb250cm9sIGFuZA0gICB0aGUgUmVw b3J0IHByb3RvY29sIGFsb25nIHdpdGggcHJlLWNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g dGhhdCBpcw0gICByZXF1aXJlZCBiZWZvcmUgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBDb250 cm9sbGVyLCBicm9hZGx5IG5hbWVkIGFzDSAgIHRoZSBMTUFQIEluZm9ybWF0aW9uIE1vZGVs IChvciBMTUFQIElNIGZvciBzaG9ydCkuICBUaGUgbWVhc3VyZW1lbnQNICAgcHJvdG9jb2xz IGFyZSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQ0gICBBcyBkZWZpbmVk IGluIFtSRkMzNDQ0XSwgdGhlIExNQVAgSU0gZGVmaW5lcyB0aGUgY29uY2VwdHMgaW52b2x2 ZWQgaW4NICAgYSBsYXJnZS1zY2FsZSBtZWFzdXJlbWVudCBwbGF0Zm9ybSBhdCBhIGhpZ2gg bGV2ZWwgb2YgYWJzdHJhY3Rpb24sDSAgIGluZGVwZW5kZW50IG9mIGFueSBzcGVjaWZpYyBp bXBsZW1lbnRhdGlvbiBvciBhY3R1YWwgcHJvdG9jb2wgdXNlZCB0bw0gICBleGNoYW5nZSB0 aGUgaW5mb3JtYXRpb24uICBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBwcm9wb3NlZA0gICBp bmZvcm1hdGlvbiBtb2RlbCBjYW4gYmUgdXNlZCB3aXRoIGRpZmZlcmVudCBwcm90b2NvbHMg aW4gZGlmZmVyZW50DSAgIG1lYXN1cmVtZW50IHBsYXRmb3JtIGFyY2hpdGVjdHVyZXMgYW5k IGFjcm9zcyBkaWZmZXJlbnQgdHlwZXMgb2YgTUENICAgZGV2aWNlcyAoZS5nLiwgaG9tZSBn YXRld2F5LCBzbWFydHBob25lLCBQQywgcm91dGVyKS4NDSAgIFRoZSBkZWZpbml0aW9uIG9m IGFuIEluZm9ybWF0aW9uIE1vZGVsIHNlcnZlcyBhIG51bWJlciBvZiBwdXJwb3NlczoNDSAg IDEuICBUbyBndWlkZSB0aGUgc3RhbmRhcmRpc2F0aW9uIG9mIG9uZSBvciBtb3JlIENvbnRy b2wgYW5kIFJlcG9ydA0gICAgICAgcHJvdG9jb2wgYW5kIGRhdGEgbW9kZWwgaW1wbGVtZW50 YXRpb25zDQ0NDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDE4 LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICBGZWJydWFyeSAyMDE0DQ0N ICAgMi4gIFRvIGVuYWJsZSBoaWdoLWxldmVsIGludGVyLW9wZXJhYmlsaXR5IGJldHdlZW4g ZGlmZmVyZW50IENvbnRyb2wNICAgICAgIGFuZCBSZXBvcnQgcHJvdG9jb2xzIGJ5IGZhY2ls aXRhdGluZyB0cmFuc2xhdGlvbiBiZXR3ZWVuIHRoZWlyDSAgICAgICByZXNwZWN0aXZlIGRh dGEgbW9kZWxzIHN1Y2ggdGhhdCBhIENvbnRyb2xsZXIgY291bGQgaW5zdHJ1Y3Qgc3ViLQ0g ICAgICAgcG9wdWxhdGlvbnMgb2YgTUFzIHVzaW5nIGRpZmZlcmVudCBwcm90b2NvbHMNDSAg IDMuICBUbyBmcm9tIGZvcm0gYWdyZWVtZW50IG9mIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMg dG8gYmUgaGVsZCBieSBhbiBNQQ0gICAgICAgYW5kIHBhc3NlZCBvdmVyIHRoZSBDb250cm9s IGFuZCBSZXBvcnQgaW50ZXJmYWNlcyBhbmQgc3VwcG9ydCB0aGUNICAgICAgIGZ1bmN0aW9u YWxpdHkgZGVzY3JpYmVkIGluIHRoZSBMTUFQIGZyYW1ld29yaw0NICAgNC4gIEVuYWJsZSBl eGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIHRvIGJlIGFzc2Vzc2VkIGZvcg0g ICAgICAgdGhlaXIgc3VpdGFiaWxpdHkgYXMgcGFydCBvZiBhIGxhcmdlLXNjYWxlIG1lYXN1 cmVtZW50IHN5c3RlbQ0NDTIuICBOb3RhdGlvbg0NICAgVGhpcyBkb2N1bWVudCB1c2UgYW4g YWRhcHRhdGlvbiBvZiB0aGUgQy1zdHlsZSBzdHJ1Y3QFIG5vdGF0aW9uIHRvDSAgIGRlZmlu ZSB0aGUgZmllbGRzIChuYW1lcy92YWx1ZXMpIG9mIHRoZSBvYmplY3RzIG9mIHRoZSBpbmZv cm1hdGlvbg0gICBtb2RlbC4gIEFuIG9wdGlvbmFsIGZpZWxkIGlzIGVuY2xvc2VkIGJ5IFsg XSwgYW5kIGFuIGFycmF5IGlzDSAgIGluZGljYXRlZCBieSB0d28gbnVtYmVycyBpbiBhbmds ZSBicmFja2V0cywgPG0uLm4+Piwgd2hlcmUgbQ0gICBpbmRpY2F0ZXMgdGhlIG1pbmltYWwg bnVtYmVyIG9mIHZhbHVlcywgYW5kIG4gaXMgdGhlIG1heGltdW0uICBUaGUNICAgc3ltYm9s ICogZm9yIG4gbWVhbnMgbm8gdXBwZXIgYm91bmQuDQ0NMy4gIExNQVAgSW5mb3JtYXRpb24g TW9kZWwNDTMuMS4gIEluZm9ybWF0aW9uIFN0cnVjdHVyZQ0NICAgVGhlIGluZm9ybWF0aW9u IGRlc2NyaWJlZCBoZXJlaW4gcmVsYXRlcyB0byB0aGUgaW5mb3JtYXRpb24gc3RvcmVkLA0g ICByZWNlaXZlZCBvciB0cmFuc21pdHRlZCBieSBhIE1lYXN1cmVtZW50IEFnZW50IGFzIGRl c2NyaWJlZCB3aXRoaW4NICAgdGhlIExNQVAgZnJhbWV3b3JrIFtJLUQuaWV0Zi1sbWFwLWZy YW1ld29ya10uICBBcyBzdWNoLCBzb21lIHN1YnNldHMNICAgb2YgdGhpcyBpbmZvcm1hdGlv biBtb2RlbCBhcmUgYXBwbGljYWJsZSB0byB0aGUgbWVhc3VyZW1lbnQNICAgQ29udHJvbGxl ciwgQ29sbGVjdG9yIGFuZCBzeXN0ZW1zIHRoYXQgcHJlLWNvbmZpZ3VyZSB0aGUgTWVhc3Vy ZW1lbnQNICAgQWdlbnQuICBUaGUgaW5mb3JtYXRpb24gZGVzY3JpYmVkIGluIHRoZXNlIG1v ZGVscyB3aWxsIGJlIHRyYW5zbWl0dGVkDSAgIGFjcm9zcyB0aGUgcHJvdG9jb2xzIGFuZCBp bnRlcmZhY2VzIGJldHdlZW4gdGhlIE1lYXN1cmVtZW50IEFnZW50IGFuZA0gICBzdWNoIHN5 c3RlbXMgYWNjb3JkaW5nIHRvIGEgRGF0YSBNb2RlbC4NDSAgIEZvciBjbGFyaXR5IHRoZSBp bmZvcm1hdGlvbiBtb2RlbCBpcyBkaXZpZGVkIGludG8gc2l4IHNlY3Rpb25zOg0NICAgMS4g IFByZS1Db25maWd1cmF0aW9uIEluZm9ybWF0aW9uLiAgSW5mb3JtYXRpb24gcHJlLWNvbmZp Z3VyZWQgb24gdGhlDSAgICAgICBNZWFzdXJlbWVudCBBZ2VudCBwcmlvciB0byBhbnkgY29t bXVuaWNhdGlvbiB3aXRoIG90aGVyDSAgICAgICBjb21wb25lbnRzIG9mIHRoZSBMTUFQIGFy Y2hpdGVjdHVyZSAoaS5lLiwgdGhlIENvbnRyb2xsZXIsDSAgICAgICBDb2xsZWN0b3IgYW5k IE1lYXN1cmVtZW50IFBlZXJzKSwgc3BlY2lmaWNhbGx5IGRldGFpbGluZyBob3cgdG8NICAg ICAgIGNvbW11bmljYXRlIHdpdGggYW4gaW5pdGlhbCBDb250cm9sbGVyIGFuZCB3aGV0aGVy IHRoZSBkZXZpY2UgaXMNICAgICAgIGVuYWJsZWQgdG8gcGFydGljaXBhdGUgYXMgYW4gTUEu DQ0gICAyLiAgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbi4gIEluZm9ybWF0aW9uIGRlbGl2 ZXJlZCB0byB0aGUgTUEgb24NICAgICAgIHJlZ2lzdHJhdGlvbiB3aXRoIGEgQ29udHJvbGxl ciBvciB1cGRhdGVkIGR1cmluZyBhIGxhdGVyDSAgICAgICBjb21tdW5pY2F0aW9uLCBpbiBw YXJ0aWN1bGFyIGRldGFpbGluZyBob3cgdG8gcmV0cmlldmUNDQ0NQnVyYnJpZGdlLCBldCBh bC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdl IDRdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwg ICAgICAgICAgICBGZWJydWFyeSAyMDE0DQ0NICAgICAgIG1lYXN1cmVtZW50IGFuZCByZXBv cnRpbmcgaW5zdHJ1Y3Rpb24gaW5mb3JtYXRpb24gZnJvbSBhDSAgICAgICBDb250cm9sbGVy IGFsb25nIHdpdGggaW5mb3JtYXRpb24gc3BlY2lmaWNhbGx5IGFib3V0IHRoZSBNQS4NDSAg IDMuICBJbnN0cnVjdGlvbiBJbmZvcm1hdGlvbi4gIEluZm9ybWF0aW9uIHRoYXQgaXMgcmVj ZWl2ZWQgYnkgdGhlIE1BDSAgICAgICBmcm9tIHRoZSBDb250cm9sbGVyIHBlcnRhaW5pbmcg dG8gdGhlIG1lYXN1cmVtZW50IGFuZCByZXBvcnRpbmcNICAgICAgIGNvbmZpZ3VyYXRpb24u ICBUaGlzIGluY2x1ZGVzIG1lYXN1cmVtZW50IGNvbmZpZ3VyYXRpb24sIHJlcG9ydA0gICAg ICAgY2hhbm5lbCBjb25maWd1cmF0aW9uLCBtZWFzdXJlbWVudCBzY2hlZHVsZXMgYW5kIG1l YXN1cmVtZW50DSAgICAgICBzdXBwcmVzc2lvbiBpbmZvcm1hdGlvbi4NDSAgIDQuICBNQSB0 byBDb250cm9sbGVyIEluZm9ybWF0aW9uLiAgSW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgZnJv bSB0aGUNICAgICAgIE1BIHRvIHRoZSBDb250cm9sbGVyIGRldGFpbGluZyB0aGUgcmVzdWx0 cyBvZiBhbnkgY29uZmlndXJhdGlvbg0gICAgICAgb3BlcmF0aW9ucyBhbG9uZyB3aXRoIGVy cm9yIGFuZCBzdGF0dXMgaW5mb3JtYXRpb24gZnJvbSB0aGUNICAgICAgIG9wZXJhdGlvbiBv ZiB0aGUgTUEuDQ0gICA1LiAgQ2FwYWJpbGl0eSBhbmQgU3RhdHVzIEluZm9ybWF0aW9uLiAg SW5mb3JtYXRpb24gb24gdGhlIGdlbmVyYWwNICAgICAgIHN0YXR1cyBhbmQgY2FwYWJpbGl0 aWVzIG9mIHRoZSBNQS4gIEZvciBleGFtcGxlLCB0aGUgc2V0IG9mDSAgICAgICBtZWFzdXJl bWVudHMgdGhhdCBhcmUgc3VwcG9ydGVkIG9uIHRoZSBkZXZpY2UuDQ0gICA2LiAgUmVwb3J0 aW5nIEluZm9ybWF0aW9uLiAgSW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgZnJvbSB0aGUgTUEg dG8NICAgICAgIHRoZSBDb2xsZWN0b3IgaW5jbHVkaW5nIG1lYXN1cmVtZW50IHJlc3VsdHMg YW5kIHRoZSBjb250ZXh0IGluDSAgICAgICB3aGljaCB0aGV5IHdlcmUgY29uZHVjdGVkLg0N ICAgSW4gYWRkaXRpb24gdGhlIE1BIG1heSBob2xkIGZ1cnRoZXIgaW5mb3JtYXRpb24gbm90 IGRlc2NyaWJlZCBoZXJlaW4sDSAgIGFuZCB3aGljaCBtYXkgYmUgb3B0aW9uYWxseSB0cmFu c2ZlcnJlZCB0byBvciBmcm9tIG90aGVyIHN5c3RlbXMNICAgaW5jbHVkaW5nIHRoZSBDb250 cm9sbGVyIGFuZCBDb2xsZWN0b3IuICBPbmUgZXhhbXBsZSBvZiBpbmZvcm1hdGlvbg0gICBp biB0aGlzIGNhdGVnb3J5IGlzIHN1YnNjcmliZXIgb3IgbGluZSBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZQ0gICByZXBvcnRlZCBieSB0aGUgTUEgYXMgb3B0aW9uYWwgZmllbGRzIGluIHRo ZSByZXBvcnRpbmcgY29tbXVuaWNhdGlvbg0gICB0byBhIENvbGxlY3Rvci4NDSAgIEl0IHNo b3VsZCBhbHNvIGJlIG5vdGVkIHRoYXQgdGhlIE1BIG1heSBiZSBpbiBjb21tdW5pY2F0aW9u IHdpdGgNICAgb3RoZXIgbWFuYWdlbWVudCBzeXN0ZW1zIHdoaWNoIG1heSBiZSByZXNwb25z aWJsZSBmb3IgY29uZmlndXJpbmcgYW5kDSAgIHJldHJpZXZpbmcgaW5mb3JtYXRpb24gZnJv bSB0aGUgTUEgZGV2aWNlLiAgU3VjaCBzeXN0ZW1zLCB3aGVyZQ0gICBhdmFpbGFibGUsIGNh biBwZXJmb3JtIGFuIGltcG9ydGFudCByb2xlIGluIHRyYW5zZmVycmluZyB0aGUgcHJlLQ0g ICBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRvIHRoZSBNQSBvciBlbmFibGluZy9kaXNh YmxpbmcgdGhlDSAgIG1lYXN1cmVtZW50IGZ1bmN0aW9uYWxpdHkgb2YgdGhlIE1BLg0NICAg VGhlIEluZm9ybWF0aW9uIE1vZGVsIGlzIGRpdmlkZWQgaW50byBzdWItc2VjdGlvbnMgZm9y IGEgbnVtYmVyIG9mDSAgIHJlYXNvbnMuICBGaXJzdGx5IHRoZSBncm91cGluZyBvZiBpbmZv cm1hdGlvbiBmYWNpbGl0YXRlcyByZWFkZXINICAgdW5kZXJzdGFuZGluZy4gIFNlY29uZGx5 LCB0aGUgcGFydGljdWxhciBncm91cGluZ3MgY2hvc2VuIGFyZQ0gICBleHBlY3RlZCB0byBt YXAgdG8gZGlmZmVyZW50IHByb3RvY29scyBvciBkaWZmZXJlbnQgdHJhbnNtaXNzaW9ucw0g ICB3aXRoaW4gdGhvc2UgcHJvdG9jb2xzLg0NMy4yLiAgUHJlLUNvbmZpZ3VyYXRpb24gSW5m b3JtYXRpb24NDSAgIFRoaXMgaW5mb3JtYXRpb24gaXMgdGhlIG1pbmltYWwgaW5mb3JtYXRp b24gdGhhdCBuZWVkcyB0byBiZSBwcmUtDSAgIGNvbmZpZ3VyZWQgdG8gdGhlIE1BIGluIG9y ZGVyIGZvciBpdCB0byBzdWNjZXNzZnVsbHkgY29tbXVuaWNhdGUgd2l0aA0gICBhIENvbnRy b2xsZXIgZHVyaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4NDQ0NDUJ1cmJyaWRnZSwg ZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAxNCAgICAgICAgICAgICAgICBb UGFnZSA1XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1v ZGVsICAgICAgICAgICAgRmVicnVhcnkgMjAxNA0NDSAgIFRoaXMgcHJlLWNvbmZpZ3VyYXRp b24gaW5mb3JtYXRpb24gbmVlZHMgdG8gaW5jbHVkZSBhIFVSTCBvZiB0aGUNICAgaW5pdGlh bCBDb250cm9sbGVyIHdoZXJlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gY2FuIGJlIHJl dHJpZXZlZA0gICBhbG9uZyB3aXRoIHRoZSBzZWN1cml0eSBpbmZvcm1hdGlvbiByZXF1aXJl ZCBmb3IgdGhlIGNvbW11bmljYXRpb24NICAgaW5jbHVkaW5nIHRoZSBjZXJ0aWZpY2F0ZSBv ZiB0aGUgQ29udHJvbGxlciAob3IgdGhlIGNlcnRpZmljYXRlIG9mDSAgIHRoZSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eSB3aGljaCB3YXMgdXNlZCB0byBpc3N1ZSB0aGUgY2VydGlmaWNh dGUNICAgZm9yIHRoZSBDb250cm9sbGVyKSBhcyB3ZWxsIGFzIHRoZSB0aW1pbmcgZm9yIHRo YXQgY29tbXVuaWNhdGlvbi4NICAgQWxsIHRoaXMgaXMgZXhwcmVzc2VkIGFzIHRoZSBJbnN0 cnVjdGlvbiBDaGFubmVsLiAgQXMgcGFydCBvZiB0aGUNICAgSW5zdHJ1Y3Rpb24gQ2hhbm5l bCwgBVR0aGUgTUEncyBzZWN1cml0eSBpbmZvcm1hdGlvbiBpcyBjb25maWd1cmVkDSAgIHdo aWNoIGNhbiBiZSBlaXRoZXIgYSBjZXJ0aWZpY2F0ZSBhbmQgYSBwcml2YXRlIGtleSBvciBh IHBhc3N3b3JkLA0gICBkZXBlbmRpbmcgb24gdGhlIHNlY3VyaXR5IHNvbHV0aW9uIHVzZWQu DQ0gICBUaGUgTUEgbWF5IGFscmVhZHkgYmUgcHJlLWNvbmZpZ3VyZWQgd2l0aCBhbiBNQSBJ RCwgb3IgbWF5IHVzZSBhDSAgIERldmljZSBJRCBpbiB0aGUgaW5pdGlhbCBDb250cm9sbGVy IGNvbnRhY3QgYmVmb3JlIGl0IGlzIGFzc2lnbmVkIGFuDSAgIE1BIElELiAgVGhlIERldmlj ZSBJRCBtYXkgYmUgYSBNQUMgYWRkcmVzcyBvciBzb21lIG90aGVyIGRldmljZQ0gICBpZGVu dGlmaWVyIGV4cHJlc3NlZCBhcyBhIFVSTi4NDSAgIERldGFpbCBvZiB0aGUgaW5mb3JtYXRp b24gbW9kZWwgZWxlbWVudHM6DQ0gICBvYmplY3Qgew0gICAgICAgbWEtY2hhbm5lbC1vYmog ICAgICBtYS1pbnN0cnVjdGlvbi1jaGFubmVsOw0gICAgICAgbWEtY2hhbm5lbC1vYmogICAg ICBtYS1tYS10by1jb250cm9sbGVyLWNoYW5uZWw7DSAgICAgICBbdXJuICAgICAgICAgICAg ICAgIG1hLWRldmljZS1pZDtdDSAgICAgICBbdXVpZCAgICAgICAgICAgICAgIG1hLWFnZW50 LWlkO10NICAgfSBtYS1wcmVjb25maWctb2JqOw0NICAgVGhlIGRldGFpbCBvZiB0aGUgQ2hh bm5lbCBvYmplY3QgaXMgZGVzY3JpYmVkIGxhdGVyIHNpbmNlIGl0IGlzDSAgIGNvbW1vbiB0 byBzZXZlcmFsIHBhcnRzIG9mIHRoZSBpbmZvcm1hdGlvbiBtb2RlbC4NDTMuMy4gIENvbmZp Z3VyYXRpb24gSW5mb3JtYXRpb24NDSAgIER1cmluZyByZWdpc3RyYXRpb24gb3IgYXQgYW55 IGxhdGVyIHBvaW50IGF0IHdoaWNoIHRoZSBNQSBjb250YWN0cw0gICB0aGUgQ29udHJvbGxl ciwgdGhlIGNob2ljZSBvZiBDb250cm9sbGVyIGFuZCBkZXRhaWxzIGZvciB0aGUgdGltaW5n DSAgIG9mIGNvbW11bmljYXRpb24gd2l0aCB0aGUgQ29udHJvbGxlciBjYW4gYmUgY2hhbmdl ZCAoYXMgY2FwdHVyZWQgYnkNICAgdGhlIEluc3RydWN0aW9uIENoYW5uZWwgaW5mb3JtYXRp b24gb2JqZWN0KS4gIEZvciBleGFtcGxlIHRoZSBwcmUtDSAgIGNvbmZpZ3VyZWQgQ29udHJv bGxlciBtYXkgYmUgcmVwbGFjZWQgd2l0aCBhIHNwZWNpZmljIENvbnRyb2xsZXIgdGhhdA0g ICBpcyBtb3JlIGFwcHJvcHJpYXRlIHRvIHRoZSBNQSBkZXZpY2UgdHlwZSwgbG9jYXRpb24g b3INICAgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBuZXR3b3JrIChlLmcuIGFjY2VzcyB0ZWNo bm9sb2d5IHR5cGUgb3INICAgYnJvYWRiYW5kIHByb2R1Y3QpLiAgVGhlIGluaXRpYWwgY29t bXVuaWNhdGlvbiB0aW1pbmcgb2JqZWN0IG1heSBiZQ0gICByZXBsYWNlZCB3aXRoIG9uZSBt b3JlIHJlbGV2YW50IHRvIHJvdXRpbmUgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUNICAg TUEgYW5kIHRoZSBDb250cm9sbGVyLg0NICAgSW4gYWRkaXRpb24gdGhlIE1BIHdpbGwgYmUg Z2l2ZW4gZnVydGhlciBpdGVtcyBvZiBpbmZvcm1hdGlvbiB0aGF0DSAgIHJlbGF0ZSBzcGVj aWZpY2FsbHkgdG8gdGhlIE1BIHJhdGhlciB0aGFuIHRoZSBtZWFzdXJlbWVudHMgaXQgaXMg dG8NICAgY29uZHVjdCBvciBob3cgdG8gcmVwb3J0IHJlc3VsdHMuICBUaGUgYXNzaWdubWVu dCBvZiBhbiBJRCB0byB0aGUgTUENICAgaXMgbWFuZGF0b3J5LiAgT3B0aW9uYWxseSBhIEdy b3VwIElEIG1heSBhbHNvIGJlIGdpdmVuIHdoaWNoDSAgIGlkZW50aWZpZXMgYSBncm91cCBv ZiBpbnRlcmVzdCB0byB3aGljaCB0aGF0IE1BIGJlbG9uZ3MuICBGb3IgZXhhbXBsZQ0gICB0 aGUgZ3JvdXAgY291bGQgcmVwcmVzZW50IGFuIElTUCwgYnJvYWRiYW5kIHByb2R1Y3QsIHRl Y2hub2xvZ3ksDSAgIG1hcmtldCBjbGFzc2lmaWNhdGlvbiwgZ2VvZ3JhcGhpYyByZWdpb24s IG9yIGEgY29tYmluYXRpb24gb2YNDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4cGly ZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDZdDQwNSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICBGZWJy dWFyeSAyMDE0DQ0NICAgbXVsdGlwbGUgc3VjaCBjaGFyYWN0ZXJpc3RpY3MuICBXaGVyZSB0 aGUgTWVhc3VyZW1lbnQgR3JvdXAgSUQgaXMgc2V0DSAgIGFuIGFkZGl0aW9uYWwgZmxhZyAo dGhlIFJlcG9ydCBNQSBJRCBmbGFnKSBpcyByZXF1aXJlZCB0byBjb250cm9sDSAgIHdoZXRo ZXIgdGhlIE1lYXN1cmVtZW50IEFnZW50IElEIGlzIGFsc28gdG8gYmUgcmVwb3J0ZWQuICBU aGUNICAgcmVwb3J0aW5nIG9mIGEgR3JvdXAgSUQgd2l0aG91dCB0aGUgTUEgSUQgYWxsb3dz IHRoZSBNQSB0byByZW1haW4NICAgYW5vbnltb3VzLCB3aGljaCBtYXkgYmUgcGFydGljdWxh cmx5IHVzZWZ1bCB0byBwcmV2ZW50IHRyYWNraW5nIG9mDSAgIG1vYmlsZSBNQSBkZXZpY2Vz Lg0NICAgT3B0aW9uYWxseSBhbiBNQSBjYW4gYWxzbyBiZSBjb25maWd1cmVkIHRvIHN0b3Ag TWVhc3VyZW1lbnQgVGFza3MgaWYNICAgdGhlIENvbnRyb2xsZXIgaXMgdW5yZWFjaGFibGUu ICBUaGlzIGNhbiBiZSB1c2VkIGFzIGEgZmFpbC1zYWZlIHRvDSAgIHN0b3AgTWVhc3VyZW1l bnQgVGFza3MgYmVpbmcgY29uZHVjdGVkIHdoZW4gdGhlcmUgaXMgZG91YnQgdGhhdCB0aGUN ICAgSW5zdHJ1Y3Rpb24gSW5mb3JtYXRpb24gaXMgc3RpbGwgdmFsaWQuICBUaGlzIGlzIHNp bXBseSByZXByZXNlbnRlZA0gICBhcyBhIG51bWJlciBvZiBmYWlsZWQgY29tbXVuaWNhdGlv biBhdHRlbXB0cyBiZWZvcmUgTWVhc3VyZW1lbnQgVGFza3MNICAgYXJlIHN1c3BlbmRlZC4g IFRoZSBhcHByb3ByaWF0ZSBudW1iZXIgb2YgZmFpbGVkIGF0dGVtcHRzIHdpbGwgZGVwZW5k DSAgIG9uIHRoZSB0aW1pbmcgb2YgdGhlIEluc3RydWN0aW9uIENoYW5uZWwgYW5kIHRoZSBk dXJhdGlvbiBmb3Igd2hpY2gNICAgdGhlIHN5c3RlbSBpcyB3aWxsaW5nIHRvIHRvbGVyYXRl IGNvbnRpbnVlZCBvcGVyYXRpb24gd2l0aA0gICBwb3RlbnRpYWxseSBzdGFsZSBJbnN0cnVj dGlvbiBJbmZvcm1hdGlvbi4NDSAgIERldGFpbCBvZiB0aGUgYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBtb2RlbCBlbGVtZW50czoNDSAgIG9iamVjdCB7DSAgICAgICB1dWlkICAgICAgICAg ICAgICAgIG1hLWFnZW50LWlkOw0gICAgICAgbWEtY2hhbm5lbC1vYmogICAgICBtYS1pbnN0 cnVjdGlvbi1jaGFubmVsOw0gICAgICBbc3RyaW5nICAgICAgICAgICAgICBtYS1ncm91cC1p ZDtdDSAgICAgIFtib29sZWFuICAgICAgICAgICAgIG1hLXJlcG9ydC1tYS1pZC1mbGFnO10N ICAgICAgW2ludCAgICAgICAgICAgICAgICAgbWEtaW5zdHJ1Y3Rpb24tY2hhbm5lbC1mYWls dXJlLXRocmVzaG9sZDtdDSAgIH0gbWEtY29uZmlnLW9iajsNDTMuNC4gIEluc3RydWN0aW9u IEluZm9ybWF0aW9uDQ0gICBUaGUgSW5zdHJ1Y3Rpb24gaW5mb3JtYXRpb24gbW9kZWwgaGFz IGZvdXIgc3ViLWVsZW1lbnRzOg0NICAgMS4gIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJh dGlvbnMNDSAgIDIuICBSZXBvcnQgQ2hhbm5lbHMNDSAgIDMuICBNZWFzdXJlbWVudCBTY2hl ZHVsZXMNDSAgIDQuICBNZWFzdXJlbWVudCBTdXBwcmVzc2lvbg0NICAgQ29uY2VwdHVhbGx5 IGVhY2ggTWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIGRlZmluZXMgdGhlDSAgIHBh cmFtZXRlcnMgb2YgYSBNZWFzdXJlbWVudCBUYXNrIHRoYXQgdGhlIE1lYXN1cmVtZW50IEFn ZW50IChNQSkgbWF5DSAgIHBlcmZvcm0gYXQgc29tZSBwb2ludCBpbiB0aW1lLiAgSXQgZG9l cyBub3QgYnkgaXRzZWxmIGFjdHVhbGx5DSAgIGluc3RydWN0IHRoZSBNQSB0byBwZXJmb3Jt IHRoZW0gYXQgYW55IHBhcnRpY3VsYXIgdGltZSAodGhpcyBpcyBkb25lDSAgIGJ5IGEgTWVh c3VyZW1lbnQgU2NoZWR1bGUpLg0NDQ0NDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgIFtQYWdlIDddDQwNSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICBG ZWJydWFyeSAyMDE0DQ0NICAgRXhhbXBsZTogIEEgTWVhc3VyZW1lbnQgVGFzayBDb25maWd1 cmF0aW9uIG1heSBjb25maWd1cmUgYSBzaW5nbGUNICAgICAgTWVhc3VyZW1lbnQgVGFzayBm b3IgbWVhc3VyaW5nIFVEUCBsYXRlbmN5LiAgVGhlIE1lYXN1cmVtZW50IFRhc2sNICAgICAg Q29uZmlndXJhdGlvbiBjb3VsZCBkZWZpbmUgdGhlIGRlc3RpbmF0aW9uIHBvcnQgYW5kIGFk ZHJlc3MgZm9yDSAgICAgIHRoZSBtZWFzdXJlbWVudCBhcyB3ZWxsIGFzIHRoZSBkdXJhdGlv biwgaW50ZXJuYWwgcGFja2V0IHRpbWluZw0gICAgICBzdHJhdGVneSBhbmQgb3RoZXIgcGFy YW1ldGVycyAoZm9yIGV4YW1wbGUgYSBzdHJlYW0gZm9yIG9uZSBob3VyDSAgICAgIGFuZCBz ZW5kaW5nIG9uZSBwYWNrZXQgZXZlcnkgNTAwIG1zKS4gIEl0IG1heSBhbHNvIGRlZmluZSB0 aGUNICAgICAgb3V0cHV0IHR5cGUgYW5kIHBvc3NpYmxlIHBhcmFtZXRlcnMgKGZvciBleGFt cGxlIHRoZSBvdXRwdXQgdHlwZQ0gICAgICBjYW4gYmUgdGhlIDk1dGggcGVyY2VudGlsZSBt ZWFuKSB3aGVyZSB0aGUgbWVhc3VyZW1lbnQgdGFzaw0gICAgICBhY2NlcHRzIHN1Y2ggcGFy YW1ldGVycy4gIEl0IGRvZXMgTk9UIGRlZmluZSB3aGVuIHRoZSB0YXNrIHN0YXJ0cw0gICAg ICAodGhpcyBpcyBkZWZpbmVkIGJ5IHRoZSBNZWFzdXJlbWVudCBTY2hlZHVsZSBlbGVtZW50 KSwgc28gaXQgZG9lcw0gICAgICBub3QgYnkgaXRzZWxmIGluc3RydWN0IHRoZSBNQSB0byBh Y3R1YWxseSBwZXJmb3JtIHRoaXMgbWVhc3VyZW1lbnQNICAgICAgdGFzay4NDSAgIFRoZSBN ZWFzdXJlbWVudCBUYXNrIENvbmZpZ3VyYXRpb24gd2lsbCBpbmNsdWRlIGEgbG9jYWwgc2hv cnQgbmFtZQ0gICBmb3IgcmVmZXJlbmNlIGJ5IHRoZSBNZWFzdXJlbWVudCBTY2hlZHVsZSwg YWxvbmcgd2l0aCBhIHJlZ2lzdHJ5DSAgIGVudHJ5IFtJLUQuYmFnbnVsby1pcHBtLW5ldy1y ZWdpc3RyeV0gdGhhdCBkZWZpbmVzIHRoZSBNZWFzdXJlbWVudA0gICBUYXNrLiAgVGhlIE1B IGl0c2VsZiB3aWxsIHJlc29sdmUgdGhlIHJlZ2lzdHJ5IGVudHJ5IHRvIGEgbG9jYWwNICAg ZXhlY3V0YWJsZSBwcm9ncmFtLiAgSW4gYWRkaXRpb24gdGhlIE1lYXN1cmVtZW50IFRhc2sg aXMgc3BlY2lhbGlzZWQNICAgdGhyb3VnaCBhIHNldCBvZiBjb25maWd1cmF0aW9uIE9wdGlv bnMuICBUaGUgbmF0dXJlIGFuZCBudW1iZXIgb2YNICAgdGhlc2UgT3B0aW9ucyB3aWxsIGRl cGVuZCB1cG9uIHRoZSBNZWFzdXJlbWVudCBUYXNrIGFuZCB3aWxsIGJlDSAgIGRlZmluZWQg aW4gdGhlIE1lYXN1cmVtZW50IFRhc2sgUmVnaXN0cnkuICBJbiBhZGRpdGlvbiB0aGUNICAg TWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIG1heSBvcHRpb25hbGx5IGFsc28gYmUg Z2l2ZW4gYQ0gICBNZWFzdXJlbWVudCBDeWNsZSBJRC4gIFRoZSBwdXJwb3NlIG9mIHRoaXMg SUQgaXMgdG8gZWFzaWx5IGlkZW50aWZ5IGENICAgc2V0IG9mIG1lYXN1cmVtZW50IHJlc3Vs dHMgdGhhdCBoYXZlIGJlZW4gcHJvZHVjZWQgYnkgTWVhc3VyZW1lbnQNICAgVGFza3Mgd2l0 aCBjb21wYXJhYmxlIE9wdGlvbnMuICBUaGlzIElEIGlzIG1hbnVhbGx5IGluY3JlbWVudGVk IHdoZW4NICAgYW4gT3B0aW9uIGNoYW5nZSBpcyBpbXBsZW1lbnRlZCB3aGljaCBjb3VsZCBt ZWFuIHRoYXQgdHdvIHNldHMgb2YNICAgcmVzdWx0cyBzaG91bGQgbm90IGJlIGRpcmVjdGx5 IGNvbXBhcmVkLg0NICAgQSBSZXBvcnQgQ2hhbm5lbCBkZWZpbmVzIGhvdyB0byByZXBvcnQg cmVzdWx0cyB0byBhIHNpbmdsZSBDb2xsZWN0b3IuDSAgIFNldmVyYWwgUmVwb3J0IENoYW5u ZWxzIGNhbiBiZSBkZWZpbmVkIHRvIGVuYWJsZSByZXN1bHRzIHRvIGJlIHNwbGl0DSAgIG9y IGR1cGxpY2F0ZWQgYWNyb3NzIGRpZmZlcmVudCByZXBvcnQgaW50ZXJ2YWxzIG9yIGRlc3Rp bmF0aW9ucy4NICAgRS5nLiBhIHNpbmdsZSBDb2xsZWN0b3IgbWF5IGhhdmUgdGhyZWUgUmVw b3J0IENoYW5uZWxzLCBvbmUgcmVwb3J0aW5nDSAgIGhvdXJseSwgYW5vdGhlciByZXBvcnRp bmcgZGFpbHkgYW5kIGEgdGhpcmQgb24gd2hpY2ggdG8gc2VuZA0gICBpbW1lZGlhdGUgcmVz dWx0cyBmb3Igb24tZGVtYW5kIG1lYXN1cmVtZW50IHRhc2tzLiAgQWx0ZXJuYXRpdmVseQ0g ICBtdWx0aXBsZSBSZXBvcnQgQ2hhbm5lbHMgY2FuIGJlIHVzZWQgdG8gc2VuZCBNZWFzdXJl bWVudCBUYXNrIHJlc3VsdHMNICAgdG8gZGlmZmVyZW50IENvbGxlY3RvcnMuICBUaGUgZGV0 YWlscyBvZiB0aGUgQ2hhbm5lbCBlbGVtZW50IGlzDSAgIGRlc2NyaWJlZCBsYXRlciBhcyBp dCBpcyBjb21tb24gdG8gc2V2ZXJhbCBvYmplY3RzLg0NICAgQSBNZWFzdXJlbWVudCBTY2hl ZHVsZSBjb250YWlucyB0aGUgSW5zdHJ1Y3Rpb24gZnJvbSB0aGUgQ29udHJvbGxlcg0gICB0 byB0aGUgTUEgdG8gZXhlY3V0ZSBhIHNpbmdsZSBvciByZXBlYXRlZCBzZXJpZXMgb2YgTWVh c3VyZW1lbnQNICAgVGFza3MuICBFYWNoIE1lYXN1cmVtZW50IFNjaGVkdWxlIGNvbnRhaW5z IGJhc2ljYWxseSB0d28gZWxlbWVudHM6IGENICAgcmVmZXJlbmNlIHRvIGEgbGlzdCBvZiBN ZWFzdXJlbWVudCBUYXNrIENvbmZpZ3VyYXRpb24gYW5kIGEgdGltaW5nDSAgIG9iamVjdCBm b3IgdGhlIHNjaGVkdWxlLiAgVGhlIHNjaGVkdWxlIGJhc2ljYWxseSBzdGF0ZXMgd2hhdA0g ICBtZWFzdXJlbWVudCB0YXNrIHRvIHJ1biwgaG93IHRvIHJlcG9ydCB0aGUgcmVzdWx0cyBw ZXIgTWVhc3VyZW1lbnQNICAgVGFzayBDb25maWd1cmF0aW9uLCBhbmQgd2hlbiB0byBydW4g dGhlIG1lYXN1cmVtZW50IHRhc2suICBNdWx0aXBsZQ0gICBtZWFzdXJlbWVudCB0YXNrcyBp biB0aGUgbGlzdCB3aWxsIGJlIGV4ZWN1dGVkIGluIG9yZGVyBSB3aXRoIG1pbmltYWwNICAg Z2Fwc2FjY29yZGluZyB0byB0aGUgTWVhc3VyZW1lbnQgU2NoZWR1bGUuICBOb3RlIHRoYXQg dGhlIENvbnRyb2xsZXIgY2FuIGluc3RydWN0IHRoZSBNQSB0byByZXBvcnQgdG8NICAgc2V2 ZXJhbCBDb2xsZWN0b3JzIGJ5IHNwZWNpZnlpbmcgc2V2ZXJhbCBSZXBvcnQgQ2hhbm5lbHMu DQ0NDUJ1cmJyaWRnZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAxNCAg ICAgICAgICAgICAgICBbUGFnZSA4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQ IEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAgRmVicnVhcnkgMjAxNA0NDSAgIEVhY2gg TWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIG5hbWVkIGluIHRoZSBNZWFzdXJlbWVu dCBTY2hlZHVsZQ0gICBjYW4gYmUgYWxsb2NhdGVkIHRvIGluZGVwZW5kZW50IFJlcG9ydCBD aGFubmVscywgZ2l2aW5nIGZsZXhpYmlsaXR5DSAgIHRvIHJlcG9ydCBkaWZmZXJlbnQgTWVh c3VyZW1lbnQgVGFza3MgdG8gZGlmZmVyZW50IENvbGxlY3RvcnMgb3Igb24NICAgZGlmZmVy ZW50IHRpbWluZ3MuICBGdXJ0aGVybW9yZSwgYXMgZWFjaCBNZWFzdXJlbWVudCBUYXNrIG1h eSBoYXZlDSAgIG11bHRpcGxlIGRhdGEgb3V0cHV0cywgdGhlc2Ugb3V0cHV0cyBjYW4gZWFj aCBiZSBhc3NpZ25lZCB0bw0gICBkaWZmZXJlbnQgUmVwb3J0IENoYW5uZWxzLiAgRm9yIGV4 YW1wbGUgYSBNZWFzdXJlbWVudCBUYXNrIG1pZ2h0DSAgIHJlcG9ydCByb3V0aW5lIHJlc3Vs dHMgaG91cmx5IHZpYSB0aGUgQnJvYWRiYW5kIFBQUCBpbnRlcmZhY2UsIGJ1dA0gICBhbHNv IG91dHB1dCBlbWVyZ2VuY3kgY29uZGl0aW9ucyBpbW1lZGlhdGVseSB2aWEgYSBHUFJTIGNo YW5uZWwuDQ0gICBFeGFtcGxlOiAgYSBNZWFzdXJlbWVudCBTY2hlZHVsZSByZWZlcmVuY2Vz IGEgc2luZ2xlIE1lYXN1cmVtZW50IFRhc2sNICAgICAgQ29uZmlndXJhdGlvbiBmb3IgdGhl IFVEUCBsYXRlbmN5IGRlZmluZWQgaW4gdGhlIHByZXZpb3VzIGV4YW1wbGUuDSAgICAgIEl0 IHJlZmVyZW5jZXMgdGhlIFJlcG9ydCBDaGFubmVsIGluIHRoZSBwcmV2aW91cyBleGFtcGxl IHRvIHNlbmQNICAgICAgcmVzdWx0cyBpbW1lZGlhdGVseSBhcyBhdmFpbGFibGUgdG8gdGhl IHNwZWNpZmllZCBDb2xsZWN0b3IuICBUaGUNICAgICAgdGltaW5nIGlzIHNwZWNpZmllZCB0 byBydW4gdGhlIGNvbmZpZ3VyZWQgTWVhc3VyZW1lbnQgVGFzaw0gICAgICBDb25maWd1cmF0 aW9uIGV2ZXJ5IGhvdXIgYXQgMjMgbWludXRlcyBwYXN0IHRoZSBob3VyLg0NICAgTWVhc3Vy ZW1lbnQgU3VwcHJlc3Npb24gaW5mb3JtYXRpb24gaXMgdXNlZCB0byBvdmVyLXJpZGUgdGhl DSAgIE1lYXN1cmVtZW50IFNjaGVkdWxlIGFuZCBzdG9wIG1lYXN1cmVtZW50cyBmcm9tIHRo ZSBNQSBmb3IgYSBkZWZpbmVkDSAgIG9yIGluZGVmaW5pdGUgcGVyaW9kLiAgV2hpbGUgY29u Y2VwdHVhbGx5IG1lYXN1cmVtZW50cyBjYW4gYmUgc3RvcHBlZA0gICBieSBzaW1wbHkgcmVt b3ZpbmcgdGhlbSBmcm9tIHRoZSBNZWFzdXJlbWVudCBTY2hlZHVsZSwgc3BsaXR0aW5nIG91 dA0gICBzZXBhcmF0ZSBpbmZvcm1hdGlvbiBvbiBNZWFzdXJlbWVudCBTdXBwcmVzc2lvbiBh bGxvd3MgdGhpcw0gICBpbmZvcm1hdGlvbiB0byBiZSB1cGRhdGVkIG9uIHRoZSBNQSBvbiBh IGRpZmZlcmVudCB0aW1pbmcgY3ljbGUgb3INICAgcHJvdG9jb2wgaW1wbGVtZW50YXRpb24g dG8gdGhlIE1lYXN1cmVtZW50IFNjaGVkdWxlLiAgSXQgaXMgYWxzbw0gICBjb25zaWRlcmVk IHRoYXQgaXQgd2lsbCBiZSBlYXNpZXIgZm9yIGEgaHVtYW4gb3BlcmF0b3IgdG8gaW1wbGVt ZW50IGENICAgdGVtcG9yYXJ5IGV4cGxpY2l0IHN1cHByZXNzaW9uIHJhdGhlciB0aGFuIGhh dmluZyB0byBtb3ZlIHRvIGENICAgcmVkdWNlZCBTY2hlZHVsZSBhbmQgdGhlbiByb2xsLWJh Y2sgYXQgYSBsYXRlciB0aW1lLiAgVGhlIGV4cGxpY2l0DSAgIFN1cHByZXNzaW9uIGluc3Ry dWN0aW9uIG1lc3NhZ2UgaXMgYWJsZSB0byBzaW1wbHkgZW5hYmxlL2Rpc2FibGUgYWxsDSAg IE1lYXN1cmVtZW50IFRhc2tzIGFzIHdlbGwgYXMgaGF2aW5nIGZpbmUgY29udHJvbCBvbiB3 aGljaCBUYXNrcyBhcmUNICAgc3VwcHJlc3NlZC4gIFN1cHByZXNzaW9uIG9mIGJvdGggc3Bl Y2lmaWVkIE1lYXN1cmVtZW50IFRhc2tzDSAgIENvbmZpZ3VyYXRpb25zIGFuZCBNZWFzdXJl bWVudCBTY2hlZHVsZXMgaXMgc3VwcG9ydGVkLiAgU3VwcG9ydCBmb3INICAgZGlzYWJsaW5n IHNwZWNpZmljIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJhdGlvbnMgYWxsb3dzDSAgIG1h bGZ1bmN0aW9uaW5nIG9yIG1pcy1jb25maWd1cmVkIE1lYXN1cmVtZW50IFRhc2tzIG9yIE1l YXN1cmVtZW50DSAgIFRhc2sgQ29uZmlndXJhdGlvbnMgdGhhdCBoYXZlIGFuIGltcGFjdCBv biBhIHBhcnRpY3VsYXIgcGFydCBvZiB0aGUNICAgbmV0d29yayBpbmZyYXN0cnVjdHVyZSAo ZS5nLiwgYSBwYXJ0aWN1bGFyIE1lYXN1cmVtZW50IFBlZXIpIHRvIGJlDSAgIHRhcmdldHRl ZC4gIFN1cHBvcnQgZm9yIGRpc2FibGluZyBzcGVjaWZpYyBNZWFzdXJlbWVudCBTY2hlZHVs ZXMNICAgYWxsb3dzIGZvciBwYXJ0aWN1bGFybHkgaGVhdnkgY3ljbGVzIG9yIHNldHMgb2Yg bGVzcyBlc3NlbnRpYWwNICAgTWVhc3VyZW1lbnQgVGFza3MgdG8gYmUgc3VwcHJlc3NlZCBx dWlja2x5IGFuZCBlZmZlY3RpdmVseS4NDSAgIFVuc3VwcHJlc3Npb24gaXMgYWNoaWV2ZWQg dGhyb3VnaCBlaXRoZXIgb3ZlcndyaXRpbmcgdGhlIE1lYXN1cmVtZW50DSAgIFN1cHByZXNz aW9uIGluZm9ybWF0aW9uIChlLmcuIGNoYW5naW5nICdlbmFibGVkJyB0byBGYWxzZSkgb3Ig dGhyb3VnaA0gICB0aGUgdXNlIG9mIGFuIEVuZCB0aW1lIHN1Y2ggdGhhdCB0aGUgTWVhc3Vy ZW1lbnQgU3VwcHJlc3Npb24gd2lsbCBubw0gICBsb25nZXIgYmUgaW4gZWZmZWN0IGJleW9u ZCB0aGlzIHRpbWUuDQ0gICBUaGUgZ29hbCB3aGVuIGRlZmluaW5nIHRoZXNlIGZvdXIgZGlm ZmVyZW50IGVsZW1lbnRzIGlzIHRvIGFsbG93IGVhY2gNICAgcGFydCBvZiB0aGUgaW5mb3Jt YXRpb24gbW9kZWwgdG8gY2hhbmdlIHdpdGhvdXQgYWZmZWN0aW5nIHRoZSBvdGhlcg0gICB0 aHJlZSBlbGVtZW50cwUuICBGb3IgZXhhbXBsZSBpdCBpcyBlbnZpc2FnZWQgdGhhdCB0aGUg UmVwb3J0IENoYW5uZWxzDSAgIGFuZCB0aGUgc2V0IG9mIE1lYXN1cmVtZW50IFRhc2tzIENv bmZpZ3VyYXRpb25zIHdpbGwgYmUgcmVsYXRpdmVseQ0gICBzdGF0aWMuICBUaGUgTWVhc3Vy ZW1lbnQgU2NoZWR1bGUgb24gdGhlIG90aGVyIGhhbmQgaXMgbGlrZWx5IHRvIGJlDQ0NDUJ1 cmJyaWRnZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAxNCAgICAgICAg ICAgICAgICBbUGFnZSA5XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQIEluZm9y bWF0aW9uIE1vZGVsICAgICAgICAgICAgRmVicnVhcnkgMjAxNA0NDSAgIG1vcmUgZHluYW1p YyBhcyB0aGUgbWVhc3VyZW1lbnQgcGFuZWwgYW5kIHRlc3QgZnJlcXVlbmN5IGFyZSBjaGFu Z2VkDSAgIGZvciB2YXJpb3VzIGJ1c2luZXNzIGdvYWxzLiAgQW5vdGhlciBleGFtcGxlIGlz IHRoYXQgbWVhc3VyZW1lbnRzIGNhbg0gICBiZSBzdXBwcmVzc2VkIHdpdGggYSBNZWFzdXJl bWVudCBTdXBwcmVzc2lvbiBjb21tYW5kIHdpdGhvdXQgcmVtb3ZpbmcNICAgdGhlIGV4aXN0 aW5nIE1lYXN1cmVtZW50IFNjaGVkdWxlcyB0aGF0IHdvdWxkIGNvbnRpbnVlIHRvIGFwcGx5 IGFmdGVyDSAgIHRoZSBNZWFzdXJlbWVudCBTdXBwcmVzc2lvbiBleHBpcmVzIG9yIGlzIHJl bW92ZWQuICBJbiB0ZXJtcyBvZiB0aGUNICAgQ29udHJvbGxlci1NQSBjb21tdW5pY2F0aW9u IHRoaXMgY2FuIHJlZHVjZSB0aGUgZGF0YSBvdmVyaGVhZC4gIEl0DSAgIGFsc28gZW5jb3Vy YWdlcyB0aGUgcmUtdXNlIG9mIHRoZSBzYW1lIHN0YW5kYXJkIE1lYXN1cmVtZW50IFRhc2sN ICAgQ29uZmlndXJhdGlvbnMgYW5kIFJlcG9ydGluZyBDaGFubmVscyB0byBoZWxwIGVuc3Vy ZSBjb25zaXN0ZW5jeSBhbmQNICAgcmVkdWNlIGVycm9ycy4NDSAgIERlZmluaXRpb24gb2Yg dGhlIGluZm9ybWF0aW9uIG1vZGVsIGVsZW1lbnRzOg0NICAgb2JqZWN0IHsNICAgICAgIG1h LXRhc2stb2JqICAgICAgICAgbWEtdGFza3M8MC4uKj47DSAgICAgICBtYS1jaGFubmVsLW9i aiAgICAgIG1hLXJlcG9ydC1jaGFubmVsczwwLi4qPjsNICAgICAgIG1hLXNjaGVkdWxlLW9i aiAgICAgbWEtc2NoZWR1bGVzPDAuLio+Ow0gICAgICAgbWEtc3VwcHJlc3Npb24tb2JqICBt YS1zdXBwcmVzc2lvbjsNICAgfSBtYS1pbnN0cnVjdGlvbi1vYmo7DQ0NICAgb2JqZWN0IHsN ICAgICAgIHN0cmluZyAgICAgICAgICAgICAgbWEtdGFzay1uYW1lOw0gICAgICAgdXJuICAg ICAgICAgICAgICAgICBtYS10YXNrLXJlZ2lzdHJ5Ow0gICAgICAgc3RyaW5nICAgICAgICAg ICAgICBtYS10YXNrLW9wdGlvbnM8MC4uKj47DSAgICAgIFtzdHJpbmcgICAgICAgICAgICAg IG1hLXRhc2stY3ljbGUtaWQ7XQ0gICB9IG1hLXRhc2stb2JqOw0NDSAgIG9iamVjdCB7DSAg ICAgICBzdHJpbmcgICAgICAgICAgICAgIG1hLXNjaGVkdWxlLW5hbWU7DSAgICAgICBtYS1z Y2hlZC10YXNrLW9iaiAgIG1hLXNjaGVkdWxlLXRhc2tzPDAuLio+Ow0gICAgICAgbWEtdGlt aW5nLW9iaiAgICAgICBtYS1zY2hlZHVsZS10aW1pbmc7DSAgIH0gbWEtc2NoZWR1bGUtb2Jq Ow0NDSAgIG9iamVjdCB7DSAgICAgICBzdHJpbmcgICAgICAgICAgICAgIG1hLXNjaGVkdWxl LXRhc2stbmFtZTsNICAgICAgIG1hLXNjaGVkLXJlcG9ydC1vYmogbWEtc2NoZWR1bGUtdGFz ay1yZXBvcnRzPDAuLio+Ow0gICB9IG1hLXNjaGVkLXRhc2stb2JqOw0NDSAgIG9iamVjdCB7 DSAgICAgIFtpbnQgICAgICAgICAgICAgICAgIG1hLXNjaGVkdWxlLXRhc2stZmlsdGVyO10g IC8vIGRlZmF1bHQ6IGFsbA0gICAgICAgc3RyaW5nICAgICAgICAgICAgICBtYS1zY2hlZHVs ZS10YXNrLXJlcG9ydC1jaGFubmVsLW5hbWU7DSAgIH0gbWEtc2NoZWQtcmVwb3J0LW9iajsN DQ0NDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDE4LCAyMDE0 ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExN QVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICBGZWJydWFyeSAyMDE0DQ0NICAgb2Jq ZWN0IHsNICAgICAgIGJvb2xlYW4gICAgICAgICAgICAgbWEtc3VwcHJlc3Npb24tZW5hYmxl ZDsNICAgICAgW2RhdGV0aW1lICAgICAgICAgICAgbWEtc3VwcHJlc3Npb24tc3RhcnQ7XSAv LyBkZWZhdWx0OiBpbW1lZGlhdGUNICAgICAgW2RhdGV0aW1lICAgICAgICAgICAgbWEtc3Vw cHJlc3Npb24tZW5kO10gICAvLyBkZWZhdWx0OiBpbmRlZmluaXRlDSAgICAgIFtzdHJpbmcg ICAgICAgICAgICAgIG1hLXN1cHByZXNzaW9uLXRhc2stbmFtZXM8MC4uKj47XQ0gICAgICAg ICAgICAgICAgICAgICAgICAgICAvLyBkZWZhdWx0OiBhbGwgdGFza3MgaWYNICAgICAgICAg ICAgICAgICAgICAgICAgICAgLy8gbWEtc3VwcHJlc3Npb24tdGFzay1uYW1lcyBpcyBlbXB0 eQ0gICAgICBbc3RyaW5nICAgICAgICAgICAgICBtYS1zdXBwcmVzc2lvbi1zY2hlZHVsZS1u YW1lczwwLi4qPjtdDSAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIGRlZmF1bHQ6IGFs bCBzY2hlZHVsZXMgaWYNICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gbWEtc3VwcHJl c3Npb24tc2NoZWR1bGUtbmFtZXMgaXMgZW1wdHkNICAgfSBtYS1zdXBwcmVzc2lvbi1vYmo7 DQ0zLjUuICBNQSB0byBDb250cm9sbGVyIEluZm9ybWF0aW9uDQ0gICBUaGUgTUEgbWF5IHJl cG9ydCBvbiB0aGUgc3VjY2VzcyBvciBmYWlsdXJlIG9mIENvbmZpZ3VyYXRpb24gb3INICAg SW5zdHJ1Y3Rpb24gY29tbXVuaWNhdGlvbnMgZnJvbSB0aGUgQ29udHJvbGxlci4gIEluIGFk ZGl0aW9uIGZ1cnRoZXINICAgb3BlcmF0aW9uYWwgbG9ncyBtYXkgYmUgcHJvZHVjZWQgZHVy aW5nIHRoZSBvcGVyYXRpb24gb2YgdGhlIE1BIGFuZA0gICB1cGRhdGVzIHRvIGNhcGFiaWxp dGllcyBtYXkgYWxzbyBiZSByZXBvcnRlZC4gIFJlcG9ydGluZyB0aGlzDSAgIGluZm9ybWF0 aW9uIGlzIGFjaGlldmVkIHNpbXBseSBhbmQgZmxleGlibHkgaW4gZXhhY3RseSB0aGUgc2Ft ZQ0gICBtYW5uZXIgYXMgYW55IE1lYXN1cmVtZW50IFRhc2suICBXZSBtYWtlIG5vIGRpc3Rp bmN0aW9uIGJldHdlZW4gYQ0gICBNZWFzdXJlbWVudCBUYXNrIGNvbmR1Y3RpbmcgYW4gYWN0 aXZlIG9yIHBhc3NpdmUgbmV0d29yayBtZWFzdXJlbWVudA0gICBhbmQgb25lIHdoaWNoIHNv bGVseSByZXRyaWV2ZXMgc3RhdGljIGluZm9ybWF0aW9uIGZyb20gdGhlIE1BIHN1Y2ggYXMN ICAgbG9nZ2luZyBpbmZvcm1hdGlvbi4gIE9uZSBvciBtb3JlIGxvZ2dpbmcgdGFza3MgY2Fu IGJlIHByb2dyYW1tZWQgb3INICAgY29uZmlndXJlZCB0byBjYXB0dXJlIHN1YnNldHMgb2Yg dGhlIE1BIHRvIENvbnRyb2xsZXIgSW5mb3JtYXRpb24uDSAgIFRoZXNlIGxvZ2dpbmcgdGFz a3MgYXJlIHRoZW4gZXhlY3V0ZWQgYnkgTWVhc3VyZW1lbnQgU2NoZWR1bGVzIChpZg0gICBu b3QgcGVybWFuZW50bHkgcnVubmluZykgYW5kIHRoZSByZXN1bHRhbnQgZGF0YSBhc3NpZ25l ZCB0byB0aGUgTUEgdG8NICAgQ29udHJvbGxlciBDaGFubmVsLg0NICAgVGhlIHR5cGUgb2Yg TUEgdG8gQ29udHJvbGxlciBJbmZvcm1hdGlvbiB3aWxsIGZhbGwgaW50byB0aHJlZQ0gICBk aWZmZXJlbnQgY2F0ZWdvcmllczoNDSAgIDEuICBTdWNjZXNzL2ZhaWx1cmUvd2FybmluZyBt ZXNzYWdlcyBpbiByZXNwb25zZSB0byBpbmZvcm1hdGlvbg0gICAgICAgdXBkYXRlcyBmcm9t IHRoZSBDb250cm9sbGVyLiAgRmFpbHVyZSBtZXNzYWdlcyBjb3VsZCBiZSBwcm9kdWNlZA0g ICAgICAgZHVlIHRvIHNvbWUgaW5hYmlsaXR5IHRvIHJlY2VpdmUgb3IgcGFyc2UgdGhlIENv bnRyb2xsZXINICAgICAgIGNvbW11bmljYXRpb24sIG9yIGlmIHRoZSBNQSBpcyBub3QgYWJs ZSB0byBhY3QgYXMgaW5zdHJ1Y3RlZC4NICAgICAgIEZvciBleGFtcGxlOg0NICAgICAgICog ICJNZWFzdXJlbWVudCBTY2hlZHVsZXMgdXBkYXRlZCBPSyINDSAgICAgICAqICAiVW5hYmxl IHRvIHBhcnNlIEpTT04iDQ0gICAgICAgKiAgIk1pc3NpbmcgbWFuZGF0b3J5IGVsZW1lbnQ6 IE1lYXN1cmVtZW50IFRpbWluZyINDSAgICAgICAqICAiJ1N0YXJ0JyBkb2VzIG5vdCBjb25m b3JtIHRvIHNjaGVtYSAtIGV4cGVjdGVkIGRhdGV0aW1lIg0NICAgICAgICogICJEYXRlIHNw ZWNpZmllZCBpcyBpbiB0aGUgcGFzdCINDQ0NDQ1CdXJicmlkZ2UsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBBdWd1c3QgMTgsIDIwMTQgICAgICAgICAgICAgICBbUGFnZSAxMV0NDA1JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCAgICAgICAgICAg IEZlYnJ1YXJ5IDIwMTQNDQ0gICAgICAgKiAgIidIb3VyJyBtdXN0IGJlIGluIHRoZSByYW5n ZSAxLi4yNCINDSAgICAgICAqICAiU2NoZWR1bGUgQSByZWZlcnMgdG8gbm9uLWV4aXN0ZW50 IE1lYXN1cmVtZW50IFRhc2sNICAgICAgICAgIENvbmZpZ3VyYXRpb24iDQ0gICAgICAgKiAg Ik1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJhdGlvbiBYIHJlZ2lzdHJ5IGVudHJ5IFkgbm90 IGZvdW5kIg0NICAgICAgICogICJVcGRhdGVkIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJh dGlvbnMgZG8gbm90IGluY2x1ZGUgTSB1c2VkDSAgICAgICAgICBieSBNZWFzdXJlbWVudCBT Y2hlZHVsZSBOIg0NICAgMi4gIE9wZXJhdGlvbmFsIHVwZGF0ZXMgZnJvbSB0aGUgTUEuICBG b3IgZXhhbXBsZToNDSAgICAgICAqICAiT3V0IG9mIG1lbW9yeTogY2Fubm90IHJlY29yZCBy ZXN1bHQiDQ0gICAgICAgKiAgIkNvbGxlY3RvciAnY29sbGVjdG9yLmV4YW1wbGUuY29tJyBu b3QgcmVzcG9uZGluZyINDSAgICAgICAqICAiVW5leHBlY3RlZCByZXN0YXJ0Ig0NICAgICAg ICogICJTdXBwcmVzc2lvbiB0aW1lb3V0Ig0NICAgICAgICogICJGYWlsZWQgdG8gZXhlY3V0 ZSBNZWFzdXJlbWVudCBUYXNrIENvbmZpZ3VyYXRpb24gSCINBQ0gICAzLiAgU3RhdHVzIHVw ZGF0ZXMgZnJvbSB0aGUgTUEuICBGb3IgZXhhbXBsZToNDSAgICAgICAqICAiSW50ZXJmYWNl IGFkZGVkOiBldGgzICINDSAgICAgICAqICAiU3VwcG9ydGVkIG1lYXN1cmVtZW50cyB1cGRh dGVkIg0NICAgICAgICogICJOZXcgSVAgYWRkcmVzcyBvbiBldGgwOiB4eHgueHh4Lnh4eC54 eHgiDQ0gICBUaGlzIEluZm9ybWF0aW9uIE1vZGVsIGRvY3VtZW50IGRvZXMgbm90IGRldGFp bCB0aGUgcHJlY2lzZSBmb3JtYXQgb2YNICAgbG9nZ2luZyBpbmZvcm1hdGlvbiBzaW5jZSBp dCBpcyB0byBhIGxhcmdlIGV4dGVuZCBwcm90b2NvbCBhbmQNICAgbWVhc3VyZW1lbnQgTWVh c3VyZW1lbnQgdGFzayBUYXNrIHNwZWNpZmljLiAgSG93ZXZlciwgc29tZSBjb21tb24gaW5m b3JtYXRpb24gY2FuIGJlDSAgIGlkZW50aWZpZWQuDQ0gICBNQSBMb2dnaW5nIGluZm9ybWF0 aW9uIG1vZGVsIGVsZW1lbnRzOg0NICAgb2JqZWN0IHsNICAgICAgIHV1aWQgICAgICAgICAg ICAgICAgbWEtbG9nLWFnZW50LWlkOw0gICAgICAgZGF0ZXRpbWUgICAgICAgICAgICBtYS1s b2ctZXZlbnQtdGltZTsNICAgICAgIGNvZGUgICAgICAgICAgICAgICAgbWEtbG9nLWNvZGU7 DSAgICAgICBzdHJpbmcgICAgICAgICAgICAgIG1hLWxvZy1kZXNjcmlwdGlvbjsNICAgfSBt YS1sb2ctb2JqOw0NDQ0NDQ0NDUJ1cmJyaWRnZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAxOCwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0MDUludGVybmV0LURyYWZ0 ICAgICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAgRmVicnVhcnkg MjAxNA0NDTMuNi4gIENhcGFiaWxpdHkgYW5kIFN0YXR1cyBJbmZvcm1hdGlvbg0NICAgVGhl IE1BIHdpbGwgaG9sZCBDYXBhYmlsaXR5IEluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIHJldHJp ZXZlZCBieSBhDSAgIENvbnRyb2xsZXIuICBDYXBhYmlsaXRpZXMgaW5jbHVkZSB0aGUgaW50 ZXJmYWNlIGRldGFpbHMgYXZhaWxhYmxlIHRvDSAgIE1lYXN1cmVtZW50IFRhc2tzIGFuZCBS ZXBvcnRzIGFzIHdlbGwgYXMgdGhlIHNldCBvZiBNZWFzdXJlbWVudCBUYXNrcw0gICB0aGF0 IGFyZSBhY3R1YWxseSBpbnN0YWxsZWQgb3IgYXZhaWxhYmxlIG9uIHRoZSBNQS4gIFN0YXR1 cw0gICBpbmZvcm1hdGlvbiBpbmNsdWRlcyB0aGUgdGltZXMgdGhhdCBvcGVyYXRpb25zIHdl cmUgbGFzdCBwZXJmb3JtZWQNICAgc3VjaCBhcyBjb250YWN0aW5nIHRoZSBDb250cm9sbGVy IG9yIHByb2R1Y2luZyBSZXBvcnRzLg0NICAgTUEgU3RhdHVzIGluZm9ybWF0aW9uIG1vZGVs IGVsZW1lbnRzOg0NICAgb2JqZWN0IHsNICAgICAgIHV1aWQgICAgICAgICAgICAgICAgbWEt YWdlbnQtaWQ7DSAgICAgICB1cm4gICAgICAgICAgICAgICAgIG1hLWRldmljZS1pZDsNICAg ICAgIHN0cmluZyAgICAgICAgICAgICAgbWEtaGFyZHdhcmU7DSAgICAgICBzdHJpbmcgICAg ICAgICAgICAgIG1hLWZpcm13YXJlOw0gICAgICAgc3RyaW5nICAgICAgICAgICAgICBtYS1z b2Z0d2FyZTsNICAgICAgIG1hLWludGVyZmFjZS1vYmogICAgbWEtaW50ZXJmYWNlczwwLi4q PjsNDSAgICAgICBkYXRldGltZSAgICAgICAgICAgIG1hLWxhc3QtbWVhc3VyZW1lbnQ7DSAg ICAgICBkYXRldGltZSAgICAgICAgICAgIG1hLWxhc3QtcmVwb3J0Ow0gICAgICAgZGF0ZXRp bWUgICAgICAgICAgICBtYS1sYXN0LWluc3RydWN0aW9uOw0gICAgICAgZGF0ZXRpbWUgICAg ICAgICAgICBtYS1sYXN0LWNvbmZpZ3VyYXRpb247DQ0gICAgICAgbWEtY2FwYWJpbGl0eS1v YmogICBtYS1zdXBwb3J0ZWQtbWVhc3VyZW1lbnRzPDAuLio+Ow0gICB9IG1hLXN0YXR1cy1v Ymo7DQ0NICAgb2JqZWN0IHsNICAgICAgIHN0cmluZyAgICAgICAgICAgICAgbWEtaW50ZXJm YWNlLW5hbWU7DSAgICAgICBzdHJpbmcgICAgICAgICAgICAgIG1hLWludGVyZmFjZS10eXBl Ow0gICAgICAgaW50ICAgICAgICAgICAgICAgICBtYS1pbnRlcmZhY2Utc3BlZWQ7ICAvLyBt YnBzDSAgICAgICBzdHJpbmcgICAgICAgICAgICAgIG1hLWxpbmstbGF5ZXItYWRkcmVzczsN ICAgICAgIGlwLWFkZHJlc3MgICAgICAgICAgbWEtaW50ZXJmYWNlLWlwLWFkZHJlc3Nlczww Li4qPjsNICAgICAgW2lwLWFkZHJlc3MgICAgICAgICAgbWEtaW50ZXJmYWNlLWdhdGV3YXlz PDAuLio+O10NICAgICAgW2lwLWFkZHJlc3MgICAgICAgICAgbWEtaW50ZXJmYWNlLWRucy1z ZXJ2ZXJzPDAuLio+O10NICAgfSBtYS1pbnRlcmZhY2Utb2JqOw0NDSAgIG9iamVjdCB7DSAg ICAgICB1cm4gICAgICAgICAgICAgICAgIG1hLW1lYXN1cmVtZW50LWlkOw0gICAgICBbc3Ry aW5nICAgICAgICAgICAgICBtYS1tZWFzdXJlbWVudC12ZXJzaW9uO10NICAgfSBtYS1jYXBh YmlsaXR5LW9iajsNDQ0NDQ0NDQ1CdXJicmlkZ2UsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBB dWd1c3QgMTgsIDIwMTQgICAgICAgICAgICAgICBbUGFnZSAxM10NDA1JbnRlcm5ldC1EcmFm dCAgICAgICAgICAgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCAgICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTQNDQ0zLjcuICBSZXBvcnRpbmcgSW5mb3JtYXRpb24NDSAgIEF0IGEgcG9pbnQgaW4g dGltZSBzcGVjaWZpYyBieSB0aGUgUmVwb3J0IENoYW5uZWwsIHRoZSBNQSB3aWxsDSAgIGNv bW11bmljYXRlIGEgc2V0IG9mIG1lYXN1cmVtZW50IHJlc3VsdHMgdG8gdGhlIENvbGxlY3Rv ci4gIFRoZXNlDSAgIG1lYXN1cmVtZW50IHJlc3VsdHMgc2hvdWxkIGJlIGNvbW11bmljYXRl ZCB3aXRoaW4gdGhlIGNvbnRleHQgaW4NICAgd2hpY2ggdGhleSB3ZXJlIGNvbGxlY3RlZC4F ICBUaGlzIGluY2x1ZGVzIHJlcG9ydGluZyB3aGV0aGVyIGEgTWVhc3VyZW1lbnQgVGFzayBl eHBlcmllbmNlZCBhIHNjaGVkdWxpbmcgY29uZmxpY3QuDQ0gICBJdCBzaG91bGQgYmUgbm90 ZWQgdGhhdCBDb2xsZWN0b3JzIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBtYW55IHR5cGVzDSAg IG9mIGRldmljZXMgYW5kIHN5c3RlbXMsIGluY2x1ZGluZyB0aGUgTUEgaXRzZWxmLiAgSW4g dGhpcyBtYW5uZXIgZGF0YQ0gICBmcm9tIE1lYXN1cmVtZW50IFRhc2tzIGNhbiAoYWxzbykg YmUgc3RvcmVkIGxvY2FsbHkgb24gdGhlIE1BIGFuZA0gICB1c2VkIGFzIGlucHV0IGJ5IG90 aGVyIE1lYXN1cmVtZW50IFRhc2tzLiAgVGhpcyBmYWNpbGl0YXRlcyB1c2luZyBhDSAgIGZp cnN0IE1lYXN1cmVtZW50IFRhc2sgdG8gY29udHJvbCB0aGUgb3BlcmF0aW9uIG9mIGEgbGF0 ZXINICAgTWVhc3VyZW1lbnQgVGFzayAoc3VjaCBhcyBwcm9iaW5nIGF2YWlsYWJsZSBsaW5l IHNwZWVkKSBhbmQgYWxzbyB0bw0gICBhbGxvdyBsb2NhbCBwcm9jZXNzaW5nIG9mIGRhdGEg dG8gb3V0cHV0IGFsYXJtcyAoZS5nLiB3aGVuDSAgIHBlcmZvcm1hbmNlIGRyb3BzIGZyb20g ZWFybGllciBsZXZlbHMpLg0NICAgVGhlIHJlcG9ydCBpcyBzdHJ1Y3R1cmVkIGhpZXJhcmNo aWNhbGx5IHRvIGF2b2lkIHJlcGV0aXRpb24gb2YNICAgcmVwb3J0LCBNZWFzdXJlbWVudCBB Z2VudCBhbmQgTWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uDSAgIGluZm9ybWF0aW9u LiAgVGhlIHJlcG9ydCBzdGFydHMgd2l0aCB0aGUgdGltZXN0YW1wIG9mIHRoZSByZXBvcnQN ICAgZ2VuZXJhdGlvbiBvbiB0aGUgTUEgYW5kIGRldGFpbHMgYWJvdXQgdGhlIE1BIGluY2x1 ZGluZyB0aGUgb3B0aW9uYWwNICAgTWVhc3VyZW1lbnQgQWdlbnQgSUQgYW5kIEdyb3VwIElE IChjb250cm9sbGVkIGJ5IHRoZSBDb25maWd1cmF0aW9uDSAgIEluZm9ybWF0aW9uKS4gIElu IGFkZGl0aW9uIG9wdGlvbmFsIGZ1cnRoZXIgTUEgY29udGV4dCBpbmZvcm1hdGlvbgUNICAg Y2FuIGJlIGluY2x1ZGVkIGF0IHRoaXMgcG9pbnQgc3VjaCBhcyB0aGUgbGluZSBzeW5jIHNw ZWVkIG9yIElTUCBhbmQNICAgcHJvZHVjdCBpZiBrbm93biBieSB0aGUgTUEuDQ0gICBBZnRl ciB0aGUgTUEgaW5mb3JtYXRpb24gBXRoZSByZXN1bHRzIGFyZSByZXBvcnRlZCBncm91cGVk IGludG8gdGhlDSAgIGRpZmZlcmVudCBNZWFzdXJlbWVudCBUYXNrcy4gIEVhY2ggTWVhc3Vy ZW1lbnQgVGFzayBzdGFydHMgd2l0aA0gICByZXBsaWNhdGluZyB0aGUgTWVhc3VyZW1lbnQg VGFzayBDb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGJlZm9yZSB0aGUNICAgcmVzdWx0IGhl YWRlcnMgKHRpdGxlcyBmb3IgZGF0YSBjb2x1bW5zKSBhbmQgdGhlIHJlc3VsdCBkYXRhIHJv d3MuDSAgIFRoZSByZXN1bHQgZGF0YSByb3dzIG1heSBvcHRpb25hbGx5IGluY2x1ZGUgYW4g aW5kaWNhdGlvbiBvZiB0aGUNICAgY3Jvc3MtdHJhZmZpYyAoZS5nLiwgdGhlIHRvdGFsIG51 bWJlciBvZiBvY3RldHMgb2Ygbm9uLW1lYXN1cmVtZW50DSAgIHRyYWZmaWMgcGFzc2luZyB0 aHJvdWdoIHRoZSBpbnRlcmZhY2VzIHVzZWQgYnkgYSBNZWFzdXJlbWVudCBUYXNrDSAgIGR1 cmluZyB0aGUgbWVhc3VyZW1lbnQgcGVyaW9kKS4NDSAgIFRoZSBkYXRldGltZSBmb3JtYXQg dXNlZCBmb3IgYWxsIGVsZW1lbnRzIGluIHRoZSBpbmZvcm1hdGlvbiBtb2RlbA0gICAoaS5l LiwgUmVwb3J0IERhdGUgYW5kIE1lYXN1cmVtZW50IFRpbWUgaW4gdGhlIFJlcG9ydGluZyBJ bmZvcm1hdGlvbikNICAgTVVTVCBjb25mb3JtIHRvIFJGQyAzMzM5IFtSRkMzMzM5XSBhbmQg SVNPODYwMS4NDSAgIEluZm9ybWF0aW9uIG1vZGVsIGVsZW1lbnRzOg0NICAgb2JqZWN0IHsN ICAgICAgIGRhdGV0aW1lICAgICAgICAgICAgbWEtcmVwb3J0LWRhdGU7DSAgICAgIFt1dWlk ICAgICAgICAgICAgICAgIG1hLXJlcG9ydC1hZ2VudC1pZDtdDSAgICAgIFtzdHJpbmcgICAg ICAgICAgICAgIG1hLXJlcG9ydC1ncm91cC1pZDtdDSAgICAgICBtYS1jb250ZXh0LW9iaiAg ICAgIG1hLXJlcG9ydC1jb250ZXh0PDAuLio+Ow0gICAgICAgbWEtcmVwb3J0LXRhc2stb2Jq ICBtYS1yZXBvcnQtdGFza3M8MC4uKj47DSAgIH0gbWEtcmVwb3J0LW9iajsNDQ0NDUJ1cmJy aWRnZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAxNCAgICAgICAgICAg ICAgIFtQYWdlIDE0XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQIEluZm9ybWF0 aW9uIE1vZGVsICAgICAgICAgICAgRmVicnVhcnkgMjAxNA0NDSAgIG9iamVjdCB7DSAgICAg ICBtYS10YXNrLW9iaiAgICAgICAgIG1hLXJlcG9ydC10YXNrLWNvbmZpZzsNICAgICAgIHN0 cmluZyAgICAgICAgICAgICAgbWEtcmVwb3J0LXRhc2stY29sdW1uLWhlYWRlcnM8MC4uKj47 DSAgICAgICBtYS1yZXN1bHQtcm93LW9iaiAgIG1hLXJlcG9ydC10YXNrLXJvd3M8MC4uKj47 DSAgIH0gbWEtcmVwb3J0LXRhc2stb2JqOw0NDSAgIG9iamVjdCB7DSAgICAgICBkYXRldGlt ZSAgICAgICAgICAgIG1hLXJlcG9ydC1yZXN1bHQtdGltZTsNICAgICAgW2ludCAgICAgICAg ICAgICAgICAgbWEtcmVwb3J0LXJlc3VsdC1jcm9zcy10cmFmZmljO10NICAgICAgIGRhdGEg ICAgICAgICAgICAgICAgbWEtcmVwb3J0LXJlc3VsdC12YWx1ZXM8MC4uKj47DSAgIH0gbWEt cmVzdWx0LXJvdy1vYmo7DQ0gICBUaGUgbWEtY29udGV4dC1vYmosIHdoaWNoIGNvdmVycyB0 aGluZ3MgbGlrZSBsaW5lIHNwZWVkIG9yIHRoZSBkZXZpY2UNICAgdHlwZSwgaXMgbm90IGZ1 cnRoZXIgZGV0YWlsZWQgaGVyZS4NDTMuOC4gIENoYW5uZWxzDQ0gICBBIENoYW5uZWwgZGVm aW5lcyBhIGNvbW11bmljYXRpb24gY2hhbm5lbCBiZXR3ZWVuIHRoZSBNQSBhbmQgb3RoZXJh bm90aGVyDSAgIGVsZW1lbnQgb2YgdGhlIG1lYXN1cmVtZW50IGZyYW1ld29yayBpLmUuIHdp dGggdGhlIENvbGxlY3RvciB0bw0gICByZXBvcnQgcmVzdWx0cyBiYWNrLCB0byBDb250cm9s bGVyIHRvIHJldHJpZXZlIEluc3RydWN0aW9ucyBvciBvdGhlcg0gICBpbmZvcm1hdGlvbiBl eGNoYW5nZWQgYmV0d2VlbiB0aGUgcGFydGllcy4gIFNldmVyYWwgQ2hhbm5lbHMgY2FuIGJl DSAgIGRlZmluZWQgdG8gZW5hYmxlIHJlc3VsdHMgdG8gYmUgc3BsaXQgb3IgZHVwbGljYXRl ZCBhY3Jvc3MgZGlmZmVyZW50DSAgIHJlcG9ydCBpbnRlcnZhbHMgb3IgZGVzdGluYXRpb25z LiAgRS5nLiBhIHNpbmdsZSBDb2xsZWN0b3IgbWF5IGhhdmUNICAgdGhyZWUgUmVwb3J0IENo YW5uZWxzLCBvbmUgcmVwb3J0aW5nIGhvdXJseSwgYW5vdGhlciByZXBvcnRpbmcgZGFpbHkN ICAgYW5kIGEgdGhpcmQgb24gd2hpY2ggdG8gc2VuZCBpbW1lZGlhdGUgcmVzdWx0cyBmb3Ig b24tZGVtYW5kDSAgIG1lYXN1cmVtZW50IHRhc2tzLg0NICAgRWFjaCBDaGFubmVsIGNvbnRh aW5zIHRoZSBkZXRhaWxzIG9mIHRoZSB0YXJnZXQgKGluY2x1ZGluZyBsb2NhdGlvbg0gICBh bmQgc2VjdXJpdHkgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgY2VydGlmaWNhdGUpLCBhbmQg dGhlIHRpbWluZyBmb3INICAgdGhlIGNvbW11bmljYXRpb24gaS5lLiB3aGVuIHRvIGVzdGFi bGlzaCB0aGUgY29tbXVuaWNhdGlvbi4gIFRoZQ0gICBjZXJ0aWZpY2F0ZSBjYW4gYmUgdGhl IGRpZ2l0YWwgY2VydGlmaWNhdGUgYXNzb2NpYXRlZCB0byB0aGUgRlFETiBpbg0gICB0aGUg VVJMIG9yIGl0IGNhbiBiZSB0aGUgY2VydGlmaWNhdGUgb2YgdGhlIENlcnRpZmljYXRpb24g QXV0aG9yaXR5DSAgIHRoYXQgd2FzIHVzZWQgdG8gaXNzdWUgdGhlIGNlcnRpZmljYXRlIGZv ciB0aGUgRlFETiAoRnVsbHkgUXVhbGlmaWVkDSAgIERvbWFpbiBOYW1lKQUgb2YgdGhlIHRh cmdldCBVUkwgKHdoaWNoIHdpbGwgYmUgcmV0cmlldmVkIGxhdGVyIG9uDSAgIHVzaW5nIGEg Y29tbXVuaWNhdGlvbiBwcm90b2NvbCBzdWNoIGFzIFNTTCkuICBUaGUgQ2hhbm5lbCBjYW4g dXNlIHRoZQ0gICBzYW1lIHRpbWluZyBpbmZvcm1hdGlvbiBvYmplY3QgYXMgYSBNZWFzdXJl bWVudCBTY2hlZHVsZSBhbmQgdGhlDSAgIENvbnRyb2xsZXIgQ29tbXVuaWNhdGlvbiBUaW1p bmcgZGVmaW5lZCBlYXJsaWVyLiAgVGhlcmUgYXJlIHNldmVyYWwNICAgb3B0aW9ucywgc3Vj aCBhcyBpbW1lZGlhdGVseSBhZnRlciB0aGUgcmVzdWx0cyBhcmUgb2J0YWluZWQgb3IgYXQg YQ0gICBnaXZlbiBpbnRlcnZhbCBvciBjYWxlbmRhciBiYXNlZCBjeWNsZSkuICBBcyB3aXRo IHRoZSBNZWFzdXJlbWVudA0gICB0YXNrIENvbmZpZ3VyYXRpb24sIGVhY2ggQ2hhbm5lbCBp cyBhbHNvIGdpdmVuIGEgbG9jYWwgc2hvcnQgbmFtZSBieQ0gICB3aGljaCBpdCBjYW4gYmUg cmVmZXJlbmNlZCBmcm9tIGEgTWVhc3VyZW1lbnQgU2NoZWR1bGUgb3Igb3RoZXINICAgZWxl bWVudHMuDQ0gICBBcyBmb3IgTWVhc3VyZW1lbnQgVGFza3MsIG11bHRpcGxlIGludGVyZmFj ZXMgYXJlIGFsc28gc3VwcG9ydGVkLg0gICBGb3IgZXhhbXBsZSB0aGUgQ29udHJvbGxlciBj b3VsZCBjaG9vc2UgdG8gcmVjZWl2ZSBzb21lIHJlc3VsdHMgb3Zlcg0gICBHUFJTLiAgVGhp cyBpcyBlc3BlY2lhbGx5IHVzZWZ1bCB3aGVuIHN1Y2ggcmVzdWx0cyBpbmRpY2F0ZSB0aGUg bG9zcw0gICBvZiBjb25uZWN0aXZpdHkgb24gYSBkaWZmZXJlbnQgbmV0d29yayBpbnRlcmZh Y2UuDQ0NDUJ1cmJyaWRnZSwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAx NCAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBM TUFQIEluZm9ybWF0aW9uIE1vZGVsICAgICAgICAgICAgRmVicnVhcnkgMjAxNA0NDSAgIEZh Y2lsaXR5IEZ1bmN0aW9uYWxpdHkgaXMgYWxzbyBwcm92aWRlZCBmb3IgdGhlIENvbnRyb2xs ZXIgdG8gY2hvb3NlIHdoZXRoZXIgdG8NICAgcmVjZWl2ZSBlbXB0eSByZXBvcnRzIHdoZXJl IHRoZXJlIGlzIG5vIE1lYXN1cmVtZW50IFRhc2sgaW5mb3JtYXRpb24uDSAgIEluIHNvbWUg Y2FzZXMgdGhpcyBtYXkgYmUgZGVzaXJhYmxlIHRvIG1vbml0b3IgdGhlIGhlYWx0aCBvZiB0 aGUNICAgbWVhc3VyZW1lbnQgc3lzdGVtLg0NICAgRXhhbXBsZTogIEEgQ2hhbm5lbCB1c2lu ZyBmb3IgcmVwb3J0aW5nIHJlc3VsdHMgbWF5IHNwZWNpZnkgdGhhdA0gICAgICByZXN1bHRz IGFyZSB0byBiZSBzZW50IHRvIHRoZSBVUkwNICAgICAgKGh0dHBzOi8vY29sbGVjdG9yLmZv by5vcmcvcmVwb3J0LyksIHVzaW5nIHRoZSBhcHByb3ByaWF0ZSBkaWdpdGFsDSAgICAgIGNl cnRpZmljYXRlIHRvIGVzdGFibGlzaCBhIHNlY3VyZSBjaGFubmVsLiAgVGhlIENoYW5uZWwg c3BlY2lmaWVzDSAgICAgIHRoYXQgdGhlIHJlc3VsdHMgYXJlIHRvIGJlIHNlbnQgaW1tZWRp YXRlbHkgYXMgYXZhaWxhYmxlIGFuZCBub3QNICAgICAgYmF0Y2hlZC4NDQ0gICBvYmplY3Qg ew0gICAgICAgc3RyaW5nICAgICAgICAgICAgICBtYS1jaGFubmVsLW5hbWU7DSAgICAgICB1 cmwgICAgICAgICAgICAgICAgIG1hLWNoYW5uZWwtdGFyZ2V0Ow0gICAgICAgY2VydGlmaWNh dGUgICAgICAgICBtYS1jaGFubmVsLWNlcnRpZmljYXRlOw0gICAgICAgbWEtdGltaW5nLW9i aiAgICAgICBtYS1jaGFubmVsLXRpbWluZzsNICAgICAgW3N0cmluZyAgICAgICAgICAgICAg bWEtY2hhbm5lbC1pbnRlcmZhY2UtbmFtZTtdDSAgICAgIFtib29sZWFuICAgICAgICAgICAg IG1hLWNoYW5uZWwtY29ubmVjdC1hbHdheXM7XQ0gICAgICAgICAgICAgICAgICAgICAgICAg ICAvLyBkZWZhdWx0OiBmYWxzZQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAvLyAob25s eSBjb25uZWN0IHdoZW4gZGF0YSBpcyBwZW5kaW5nKQ0gICB9IG1hLWNoYW5uZWwtb2JqOw0N My45LiAgVGltaW5nIEluZm9ybWF0aW9uDQ0gICBUaGUgVGltaW5nIGluZm9ybWF0aW9uIG9i amVjdCB1c2VkIHRocm91Z2hvdXQgdGhlIGluZm9ybWF0aW9uIG1vZGVscw0gICBjYW4gdGFr ZSBvbmUgb2YgZm91ciBkaWZmZXJlbnQgZm9ybXM6DQ0gICAxLiAgUGVyaW9kaWMuICBTcGVj aWZpZXMgYSBzdGFydCwgZW5kIGFuZCBpbnRlcnZhbCB0aW1lIGluDSAgICAgICBtaWxsaXNl Y29uZHMNDSAgIDIuICBDYWxlbmRhcjogU3BlY2lmaWVzIGEgY2FsZW5kYXIgYmFzZWQgcGF0 dGVybiAtIGUuZy4gMjIgbWludXRlcw0gICAgICAgcGFzdCBlYWNoIGhvdXIgb2YgdGhlIGRh eSBvbiB3ZWVrZGF5cw0NICAgMy4gIE9uZSBPZmY6IEEgc2luZ2xlIGluc3RhbmNlIG9jY3Vy cmluZyBhdCBhIHNwZWNpZmljIHRpbWUNDSAgIDQuICBJbW1lZGlhdGU6IFNob3VsZCBvY2N1 ciBhcyBzb29uIGFzIHBvc3NpYmxlDQ0gICBPcHRpb25hbGx5IGVhY2ggb2YgdGhlIGZpcnN0 IHRocmVlIG9wdGlvbnMgbWF5IGFsc28gc3BlY2lmeSBhDSAgIHJhbmRvbW5lc3MgdGhhdCBz aG91bGQgYmUgZXZhbHVhdGVkIGFuZCBhcHBsaWVkIHNlcGFyYXRlbHkgdG8gZWFjaA0gICBp bmRpY2F0ZWQgZXZlbnQuDQ0gICBUaGUgZGF0ZXRpbWUgZm9ybWF0IHVzZWQgZm9yIGFsbCBl bGVtZW50cyBpbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwNICAgKGkuZS4sIFJlcG9ydCBEYXRl IGFuZCBNZWFzdXJlbWVudCBUaW1lIGluIHRoZSBSZXBvcnRpbmcgSW5mb3JtYXRpb24pDSAg IE1VU1QgY29uZm9ybSB0byBSRkMgMzMzOSBbUkZDMzMzOV0gYW5kIElTTzg2MDEuDQ0NDQ0N QnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDE4LCAyMDE0ICAgICAg ICAgICAgICAgW1BhZ2UgMTZdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5m b3JtYXRpb24gTW9kZWwgICAgICAgICAgICBGZWJydWFyeSAyMDE0DQ0NICAgb2JqZWN0IHsN ICAgICAgW3N0cmluZyAgICAgICAgICAgICAgbWEtdGltaW5nLW5hbWU7XQ0gICAgICB1bmlv biB7DSAgICAgICAgICBtYS1wZXJpb2RpYy1vYmogIG1hLXRpbWluZy1wZXJpb2RpYzsNICAg ICAgICAgIG1hLWNhbGVuZGFyLW9iaiAgbWEtdGltaW5nLWNhbGVuZGFyOw0gICAgICAgICAg bWEtb25lLW9mZi1vYmogICBtYS10aW1pbmctb25lLW9mZjsNICAgICAgICAgIG1hLWltbWVk aWF0ZS1vYmogbWEtdGltaW5nLWltbWVkaWF0ZTsNICAgICAgfQ0gICAgICBbbWEtcmFuZG9t bmVzcy1vYmogICBtYS10aW1pbmctcmFuZG9tbmVzcztdDSAgIH0gbWEtdGltaW5nLW9iajsN DTMuOS4xLiAgUGVyaW9kaWMgVGltaW5nDQ0gICBJbmZvcm1hdGlvbiBtb2RlbCBlbGVtZW50 czoNDSAgIG9iamVjdCB7DSAgICAgIFtkYXRldGltZSAgICAgICAgICAgIG1hLXBlcmlvZGlj IHN0YXJ0O10gICAvLyBkZWZhdWx0OiBpbW1lZGlhdGUNICAgICAgW2RhdGV0aW1lICAgICAg ICAgICAgbWEtcGVyaW9kaWMtZW5kO10gICAgIC8vIGRlZmF1bHQ6IGluZGVmaW5pdGUNICAg ICAgIGludCAgICAgICAgICAgICAgICAgbWEtcGVyaW9kaWMtaW50ZXJ2YWw7IC8vIG1pbGxp c2Vjb25kcw0gICB9IG1hLXBlcmlvZGljLW9iajsNDTMuOS4yLiAgQ2FsZW5kYXIgVGltaW5n DQ0gICBDYWxlbmRhciBUaW1pbmcgc3VwcG9ydHMgdGhlIHJvdXRpbmUgZXhlY3V0aW9uIG9m IE1lYXN1cmVtZW50IFRhc2tzDSAgIGF0IHNwZWNpZmljIHRpbWVzIGFuZC9vciBvbiBzcGVj aWZpYyBkYXRlcy4gIEl0IGNhbiBzdXBwb3J0IG1vcmUNICAgZmxleGlibGUgdGltaW5nIHRo YW4gUGVyaW9kaWMgVGltaW5nIHNpbmNlIHRoZSBNZWFzdXJlbWVudCBUYXNrDSAgIGV4ZWN1 dGlvbiBkb2VzIG5vdCBoYXZlIHRvIGJlIHVuaWZvcm1seSBzcGFjZWQuICBGb3IgZXhhbXBs ZSBhDSAgIENhbGVuZGFyIFRpbWluZyBjb3VsZCBzdXBwb3J0IHRoZSBleGVjdXRpb24gb2Yg YSBNZWFzdXJlbWVudCBUYXNrDSAgIGV2ZXJ5IGhvdXIgYmV0d2VlbiA2cG0gYW5kIG1pZG5p Z2h0IG9uIHdlZWtkYXlzIG9ubHkuDQ0gICBDYWxlbmRhciBUaW1pbmcgaXMgYWxzbyByZXF1 aXJlZCB0byBwZXJmb3JtIG1lYXN1cmVtZW50cyBhdA0gICBtZWFuaW5nZnVsIGluc3RhbmNl cyBpbiByZWxhdGlvbiB0byBuZXR3b3JrIHVzYWdlIChlLmcuLCBhdCBwZWFrDSAgIHRpbWVz KS4gIElmIHRoZSBvcHRpb25hbCB0aW1lem9uZSBvZmZzZXQgaXMgbm90IHN1cHBsaWVkIHRo ZW4gbG9jYWwNICAgc3lzdGVtIHRpbWUgaXMgYXNzdW1lZC4gIFRoaXMgaXMgZXNzZW50aWFs IGluIHNvbWUgdXNlIGNhc2VzIHRvDSAgIGVuc3VyZSBjb25zaXN0ZW50IHBlYWstdGltZSBt ZWFzdXJlbWVudHMgYXMgd2VsbCBhcyBzdXBwb3J0aW5nIE1BDSAgIGRldmljZXMgdGhhdCBt YXkgYmUgaW4gYW4gdW5rbm93biB0aW1lem9uZSBvciByb2FtIGJldHdlZW4gZGlmZmVyZW50 DSAgIHRpbWV6b25lcyAoYnV0IGtub3cgdGhlaXIgb3duIHRpbWV6b25lIGluZm9ybWF0aW9u IHN1Y2ggYXMgdGhyb3VnaA0gICB0aGUgbW9iaWxlIG5ldHdvcmspLg0NICAgSW5mb3JtYXRp b24gbW9kZWwgZWxlbWVudHM6DQ0NDQ0NDQ0NDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAg IEV4cGlyZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMTddDQwNSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAg ICBGZWJydWFyeSAyMDE0DQ0NICAgb2JqZWN0IHsNICAgICAgW2RhdGV0aW1lICAgICAgICAg ICAgbWEtY2FsZW5kYXItc3RhcnQ7XSAvLyBkZWZhdWx0OiBpbW1lZGlhdGUNICAgICAgW2Rh dGV0aW1lICAgICAgICAgICAgbWEtY2FsZW5kYXItZW5kO10gICAvLyBkZWZhdWx0OiBpbmRl ZmluaXRlDSAgICAgIFtpbnQgICAgICAgICAgICAgICAgIG1hLWNhbGVuZGFyLW1vbnRoczww Li4qPjtdICAgLy8gZGVmYXVsdDogMS0xMg0gICAgICBbZGF5cyAgICAgICAgICAgICAgICBt YS1jYWxlbmRhci13ZWVrZGF5czwwLi4qPjtdIC8vIGRlZmF1bHQ6IGFsbA0gICAgICBbaW50 ICAgICAgICAgICAgICAgICBtYS1jYWxlbmRhci1ob3VyczwwLi4qPjtdICAgIC8vIGRlZmF1 bHQ6IDAtMjMNICAgICAgW2ludCAgICAgICAgICAgICAgICAgbWEtY2FsZW5kYXItbWludXRl czwwLi4qPjtdICAvLyBkZWZhdWx0OiAwLTU5DSAgICAgIFtpbnQgICAgICAgICAgICAgICAg IG1hLWNhbGVuZGFyLXNlY29uZHM8MC4uKj47XSAgLy8gZGVmYXVsdDogMC01OQ0gICAgICBb aW50ICAgICAgICAgICAgICAgICBtYS1jYWxlbmRhci10aW1lem9uZS1vZmZzZXQ7XQ0gICAg ICAgICAgICAgICAgICAgICAgICAgICAvLyBkZWZhdWx0OiBzeXN0ZW0gdGltZXpvbmUgb2Zm c2V0DSAgIH0gbWEtY2FsZW5kYXItb2JqOw0NMy45LjMuICBPbmUtT2ZmIFRpbWluZw0NICAg SW5mb3JtYXRpb24gbW9kZWwgZWxlbWVudHM6DQ0gICBvYmplY3Qgew0gICAgICAgZGF0ZXRp bWUgICAgICAgICAgICBtYS1vbmUtb2ZmLXRpbWU7DSAgIH0gbWEtb25lLW9mZi1vYmo7DQ0z LjkuNC4gIEltbWVkaWF0ZSBUaW1pbmcNDSAgIFRoZSBpbW1lZGlhdGUgdGltaW5nIG9iamVj dCBoYXMgbm8gZnVydGhlciBpbmZvcm1hdGlvbiBlbGVtZW50cy4gIFRoZQ0gICBtZWFzdXJl bWVudCBvciByZXBvcnQgaXMgc2ltcGx5IHRvIGJlIGRvbmUgYXMgc29vbiBhcyBwb3NzaWJs ZS4NDSAgIG9iamVjdCB7DSAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIGVtcHR5DSAg IH0gbWEtaW1tZWRpYXRlLW9iajsNDTMuOS41LiAgVGltaW5nIFJhbmRvbW5lc3MNDSAgIFRo ZSBUaW1pbmcgcmFuZG9tbmVzcyBvYmplY3Qgc3BlY2lmaWVzIGEgcmFuZG9tIGRpc3RyaWJ1 dGlvbiB0aGF0IGNhbg0gICBiZSBhcHBsaWVkIHRvIGFueSBzY2hlZHVsZWQgZXhlY3V0aW9u IGV2ZW50IHN1Y2ggYXMgYSBtZWFzdXJlbWVudCBvcg0gICByZXBvcnQuICBUaGUgaW50ZW50 aW9uIGl0IHRvIGJlIGFibGUgdG8gc3ByZWFkIHRoZSBsb2FkIG9uIHRoZQ0gICBDb250cm9s bGVyLCBDb2xsZWN0b3IgYW5kIG5ldHdvcmsgaW4gYW4gYXV0b21hdGVkIG1hbm5lciBmb3Ig YSBsYXJnZQ0gICBudW1iZXIgb2YgTWVhc3VyZW1lbnQgQWdlbnRzLiAgVGhlIHJhbmRvbW5l c3MgaXMgZXhwcmVzc2VkIGFzIGENICAgZGlzdHJpYnV0aW9uIChlLmcuICBQb2lzb24sIE5v cm1hbCwgVW5pZm9ybSBldGMuKSBhbG9uZyB3aXRoIHRoZQ0gICBzcHJlYWQgb3ZlciB3aGlj aCB0aGUgZGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhcHBsaWVkLiAgSW4gYWRkaXRpb25hbA0g ICBvcHRpb25hbCB1cHBlciBhbmQgbG93ZXIgYm91bmRzIGNhbiBiZSBhcHBsaWVkIHRvIGNv bnRyb2wgZXh0cmVtZQ0gICBzcHJlYWQgb2YgdGltaW5ncy4NDSAgIEluZm9ybWF0aW9uIG1v ZGVsIGVsZW1lbnRzOg0NICAgb2JqZWN0IHsNICAgICAgIHN0cmluZyAgICAgICAgICAgICAg bWEtcmFuZG9tbmVzcy1kaXN0cmlidXRpb247DSAgICAgIFtpbnQgICAgICAgICAgICAgICAg IG1hLXJhbmRvbW5lc3MtbG93ZXItY3V0O10NICAgICAgW2ludCAgICAgICAgICAgICAgICAg bWEtcmFuZG9tbmVzcy11cHBlci1jdXQ7XQ0gICAgICAgaW50ICAgICAgICAgICAgICAgICBt YS1yYW5kb21uZXNzLXNwcmVhZDsNDQ0NQnVyYnJpZGdlLCBldCBhbC4gICAgICAgIEV4cGly ZXMgQXVndXN0IDE4LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMThdDQwNSW50ZXJuZXQt RHJhZnQgICAgICAgICAgIExNQVAgSW5mb3JtYXRpb24gTW9kZWwgICAgICAgICAgICBGZWJy dWFyeSAyMDE0DQ0NICAgfSBtYS1yYW5kb21uZXNzLW9iajsNDQ00LiAgSUFOQSBDb25zaWRl cmF0aW9ucw0NICAgVGhpcyBkb2N1bWVudCBtYWtlcyBubyByZXF1ZXN0IG9mIElBTkEuDQ0g ICBOb3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUgcmVtb3ZlZCBvbiBw dWJsaWNhdGlvbiBhcyBhbg0gICBSRkMuDQ0NNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQ0gICBUaGlzIEluZm9ybWF0aW9uIE1vZGVsIGRlYWxzIHdpdGggaW5mb3JtYXRpb24gYWJv dXQgdGhlIGNvbnRyb2wgYW5kDSAgIHJlcG9ydGluZyBvZiB0aGUgTWVhc3VyZW1lbnQgQWdl bnQuICBUaGVyZSBhcmUgYnJvYWRseSB0d28gc2VjdXJpdHkNICAgY29uc2lkZXJhdGlvbnMg Zm9yIHN1Y2ggYW4gSW5mb3JtYXRpb24gTW9kZWwuICBGaXJzdGx5IHRoZQ0gICBJbmZvcm1h dGlvbiBNb2RlbCBoYXMgdG8gYmUgc3VmZmljaWVudCB0byBlc3RhYmxpc2ggc2VjdXJlDSAg IGNvbW11bmljYXRpb24gY2hhbm5lbHMgdG8gdGhlIENvbnRyb2xsZXIgYW5kIENvbGxlY3Rv ciBzdWNoIHRoYXQNICAgb3RoZXIgaW5mb3JtYXRpb24gY2FuIGJlIHNlbnQgYW5kIHJlY2Vp dmVkIHNlY3VyZWx5LiAgQWRkaXRpb25hbGx5LA0gICBhbnkgbWVjaGFuaXNtcyB0aGF0IHRo ZSBOZXR3b3JrIE9wZXJhdG9yIG9yIG90aGVyIGRldmljZQ0gICBhZG1pbmlzdHJhdG9yIGVt cGxveXMgdG8gcHJlLWNvbmZpZ3VyZSB0aGUgTUEgbXVzdCBhbHNvIGJlIHNlY3VyZSB0bw0g ICBwcm90ZWN0IHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZyb20gbW9kaWZ5aW5nIHByZS1jb25m aWd1cmF0aW9uDSAgIGluZm9ybWF0aW9uLiAgVGhlIHNlY29uZCBjb25zaWRlcmF0aW9uIGlz IHRoYXQgbm8gbWFuZGF0ZWQNICAgaW5mb3JtYXRpb24gaXRlbXMgcG9zZSBhIHJpc2sgdG8g Y29uZmlkZW50aWFsaXR5IG9yIHByaXZhY3kgZ2l2ZW4NICAgc3VjaCBzZWN1cmUgY29tbXVu aWNhdGlvbiBjaGFubmVscy4gIEZvciB0aGlzIGxhdHRlciByZWFzb24gaXRlbXMNICAgc3Vj aCBhcyB0aGUgTUEgY29udGV4dCBhbmQgTUEgSUQgYXJlIGxlZnQgb3B0aW9uYWwgYW5kIGNh biBiZQ0gICBleGNsdWRlZCBmcm9tIHNvbWUgZGVwbG95bWVudHMuICBUaGlzIHdvdWxkLCBm b3IgZXhhbXBsZSwgYWxsb3cgdGhlDSAgIE1BIHRvIHJlbWFpbiBhbm9ueW1vdXMgYW5kIGZv ciBpbmZvcm1hdGlvbiBhYm91dCBsb2NhdGlvbiBvciBvdGhlcg0gICBjb250ZXh0IHRoYXQg bWlnaHQgYmUgdXNlZCB0byBpZGVudGlmeSBvciB0cmFjayB0aGUgTUEgdG8gYmUgb21pdHRl ZA0gICBvciBibHVycmVkLg0NDTYuICBBY2tub3dsZWRnZW1lbnRzDQ0gICBUaGUgbm90YXRp b24gd2FzIGluc3BpcmVkIGJ5IHRoZSBub3RhdGlvbiB1c2VkIGluIHRoZSBBTFRPIHByb3Rv Y29sDSAgIHNwZWNpZmljYXRpb24uDQ0gICBQaGlsaXAgRWFyZGxleSwgVHJldm9yIEJ1cmJy aWRnZSwgTWFyY2VsbyBCYWdudWxvIGFuZCBKdWVyZ2VuDSAgIFNjaG9lbndhZWxkZXIgd29y ayBpbiBwYXJ0IG9uIHRoZSBMZW9uZSByZXNlYXJjaCBwcm9qZWN0LCB3aGljaA0gICByZWNl aXZlcyBmdW5kaW5nIGZyb20gdGhlIEV1cm9wZWFuIFVuaW9uIFNldmVudGggRnJhbWV3b3Jr IFByb2dyYW1tZQ0gICBbRlA3LzIwMDctMjAxM10gdW5kZXIgZ3JhbnQgYWdyZWVtZW50IG51 bWJlciAzMTc2NDcuDQ0NNy4gIFJlZmVyZW5jZXMNDQ0NDQ0NDUJ1cmJyaWRnZSwgZXQgYWwu ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxOCwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDE5 XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICBMTUFQIEluZm9ybWF0aW9uIE1vZGVsICAg ICAgICAgICAgRmVicnVhcnkgMjAxNA0NDTcuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQ0g ICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0 byBJbmRpY2F0ZQ0gICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwg UkZDIDIxMTksIE1hcmNoIDE5OTcuDQ0gICBbUkZDMzMzOV0gIEtseW5lLCBHLiwgRWQuIGFu ZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRoZQ0gICAgICAgICAgICAgIEludGVy bmV0OiBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1bHkgMjAwMi4NDTcuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNDSAgIFtJLUQuYmFnbnVsby1pcHBtLW5ldy1yZWdpc3RyeV0NICAg ICAgICAgICAgICBCYWdudWxvLCBNLiwgQnVyYnJpZGdlLCBULiwgQ3Jhd2ZvcmQsIFMuLCBF YXJkbGV5LCBQLiwgYW5kDSAgICAgICAgICAgICAgQS4gTW9ydG9uLCAiQSByZWdpc3RyeSBm b3IgY29tbW9ubHkgdXNlZCBtZXRyaWNzIiwNICAgICAgICAgICAgICBkcmFmdC1iYWdudWxv LWlwcG0tbmV3LXJlZ2lzdHJ5LTAxICh3b3JrIGluIHByb2dyZXNzKSwNICAgICAgICAgICAg ICBKdWx5IDIwMTMuDQ0gICBbSS1ELmlldGYtbG1hcC1mcmFtZXdvcmtdDSAgICAgICAgICAg ICAgRWFyZGxleSwgUC4sIE1vcnRvbiwgQS4sIEJhZ251bG8sIE0uLCBCdXJicmlkZ2UsIFQu LA0gICAgICAgICAgICAgIEFpdGtlbiwgUC4sIGFuZCBBLiBBa2h0ZXIsICJBIGZyYW1ld29y ayBmb3IgbGFyZ2Utc2NhbGUNICAgICAgICAgICAgICBtZWFzdXJlbWVudCBwbGF0Zm9ybXMg KExNQVApIiwNICAgICAgICAgICAgICBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTAzICh3 b3JrIGluIHByb2dyZXNzKSwNICAgICAgICAgICAgICBKYW51YXJ5IDIwMTQuDQ0gICBbUkZD MzQ0NF0gIFByYXMsIEEuIGFuZCBKLiBTY2hvZW53YWVsZGVyLCAiT24gdGhlIERpZmZlcmVu Y2UgYmV0d2Vlbg0gICAgICAgICAgICAgIEluZm9ybWF0aW9uIE1vZGVscyBhbmQgRGF0YSBN b2RlbHMiLCBSRkMgMzQ0NCwNICAgICAgICAgICAgICBKYW51YXJ5IDIwMDMuDQ0NQXV0aG9y cycgQWRkcmVzc2VzDQ0gICBUcmV2b3IgQnVyYnJpZGdlDSAgIEJyaXRpc2ggVGVsZWNvbQ0g ICBBZGFzdHJhbCBQYXJrLCBNYXJ0bGVzaGFtIEhlYXRoDSAgIElwc3dpY2gsICAgSVA1IDNS RQ0gICBVbml0ZWQgS2luZ2RvbQ0NDSAgIFBoaWxpcCBFYXJkbGV5DSAgIEJyaXRpc2ggVGVs ZWNvbQ0gICBBZGFzdHJhbCBQYXJrLCBNYXJ0bGVzaGFtIEhlYXRoDSAgIElwc3dpY2gsICAg SVA1IDNSRQ0gICBVbml0ZWQgS2luZ2RvbQ0NDQ0NDQ0NDQ1CdXJicmlkZ2UsIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMTgsIDIwMTQgICAgICAgICAgICAgICBbUGFnZSAyMF0N DA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgTE1BUCBJbmZvcm1hdGlvbiBNb2RlbCAgICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTQNDQ0gICBNYXJjZWxvIEJhZ251bG8NICAgVW5pdmVyc2lk YWQgQ2FybG9zIElJSSBkZSBNYWRyaWQNICAgQXYuIFVuaXZlcnNpZGFkIDMwDSAgIExlZ2Fu ZXMsIE1hZHJpZCwgICAyODkxMQ0gICBTcGFpbg0NDSAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRl cg0gICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4NICAgQ2FtcHVzIFJpbmcgMQ0gICBCcmVt ZW4sICAgMjg3NTkNICAgR2VybWFueQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ1CdXJicmlkZ2UsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTgsIDIw MTQgICAgICAgICAgICAgICBbUGFnZSAyMV0NDA0FPz8/IHN0cnVjdHVyZT8NBUkgdGhvdWdo dCB0aGUgSW5mb3JtYXRpb24gQ2hhbm5lbCB3YXMgdGhlIGNoYW5uZWwgYmV0d2VlbiB0aGUg TUEgYW5kIHRoZSBDb250cm9sbGVyIHVzZWQgdG8gY29udmV5IGNvbmZpZ3VyYXRpb24gaW5m b3JtYXRpb24gZnJvbSB0aGUgQ29udHJvbGxlciB0byB0aGUgTUEuICBXaGF0IHdhcyBkZXNj cmliZWQgYWJvdmUgdGhpcyBwb2ludCBpcyBQcmUtQ29uZmlndXJhdGlvbiBpbmZvcm1hdGlv biBwZXJmb3JtZWQgdGhyb3VnaCBhIGJvb3RzdHJhcCBvcGVyYXRpb24gd2hpY2ggbWF5IGNv bWUgZnJvbSBzb21lIHNvdXJjZSBvdGhlciB0aGFuIHRoZSBDb250cm9sbGVyLiAgVGhpcyBs YXN0IGhhbGYgb2YgdGhlIHBhcmFncmFwaCBhcHBlYXJzIHRvIGJlIGRlc2NyaWJpbmcgQ29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbiByYXRoZXIgdGhhbiBQcmUtY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbi4NDVRoaXMgY2FuIGJlIGRlbGV0ZWQgYmVjYXVzZSB0aGUgSW5mb3JtYXRp b24gQ2hhbm5lbCBpcyBhc3NvY2lhdGVkIHdpdGggQ29uZmlndXJhdGlvbiBpbmZvcm1hdGlv biBpbiBTZWN0aW9uIDMuMy4NBVJhdGhlciB0aGFuIGluIG9yZGVyLCBtdWx0aXBsZSB0YXNr cyBhcmUgcGVyZm9ybWVkIGFjY29yZGluZyB0byB0aGUgc2NoZWR1bGUuICBJZiB0aGVyZSBp cyBhIGNvbmZsaWN0IGluIHRoZSBzY2hlZHVsZSwgdGhlbiB0aGUgZmFjdCB0aGF0IHRoZXJl IHdhcyBhIGNvbmZsaWN0IG5lZWRzIHRvIGJlIHJlcG9ydGVkIGluIHRoZSByZXN1bHRzIHNv IHRoYXQgcG9zdCBwcm9jZXNzaW5nIGNhbiB0YWtlIHRoYXQgaW5mb3JtYXRpb24gaW50byBh Y2NvdW50Lg0FV2lsbCB0aGVyZSBiZSA0IGVsZW1lbnRzIG9yIDUgZWxlbWVudHM/ICBJIGhl YXJkIHRoZXJlIHdhcyBpbnRlcmVzdCBpbiBzcGxpdHRpbmcgb25lIG9mIHRoZSBlbGVtZW50 cyBpbnRvIHBhc3NpdmUgYW5kIGFjdGl2ZS4NBUlzIHRoZXJlIGEgbmVlZCB0byByZXBvcnQg d2hlbiB0aGVyZSBpcyBhIGNvbmZsaWN0IGluIHRoZSBzY2hlZHVsZT8NDSCTU2NoZWR1bGlu ZyBjb25mbGljdJQNBUluY2x1ZGluZyB3aGV0aGVyIE1lYXN1cmVtZW50IFRhc2tzIGV4cGVy aWVuY2VkIHNjaGVkdWxpbmcgY29uZmxpY3RzLg0FQXdrd2FyZCB3b3JkaW5nLiAgUGVyaGFw cywgk0FkZGl0aW9uYWwgTUEgY29udGV4dCBpbmZvcm1hdGlvbiBtYXkgb3B0aW9uYWxseSBi ZSBpbmNsdWRlZCBhdCB0aGlzIHBvaW50hZQNBVNvbWV0aGluZyBzZWVtcyB0byBiZSBtaXNz aW5nIGZyb20gdGhpcyBwaHJhc2UuICBBcyBpcywgdGhlIHNlbnRlbmNlIGRvZXMgbm90IG1h a2Ugc2Vuc2UuDQVNb3ZlIHRoaXMgdG8gdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgRlFETiBp biB0aGUgZHJhZnQuDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAviYAAMMmAADHJgAA yCYAAFAoAABRKAAAaToAAMM6AADEOgAAxToAAMY6AAASVgAAGlYAAPPXx7TzpvOKfGxQ8zQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcACIEVaMgWEAAWaD0JqwAXaNw6 NwBPSgMAUUoDAF5KAwBjSAEAZGgAAAAAZGgAAAAAZGiJWiNHNwAIgRVoyBYQABZoPQmrABdo ED3QAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABkaINaI0cfAQiBBEgBAAVog1ojRxZo ED3QAE9KAwBRSgMAXkoDABsDagAAAAAWaBA90AAwShEAT0oEAFFKBABVCAE3AAiBFWjIFhAA Fmg9CasAF2g9CasAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRod1ojRxsDagAAAAAW aIUN0AAwShEAT0oEAFFKBABVCAElAQiBBEgBAAVoEVojRxVoyBYQABZohQ3QAE9KAwBRSgMA XkoDAB8BCIEESAEABWgRWiNHFmiFDdAAT0oDAFFKAwBeSgMANwAIgRVoyBYQABZoPQmrABdo hQ3QAE9KAwBRSgMAXkoDAGNIAQBkaAAAAABkaAAAAABkaBFaI0cYFWjIFhAAFmg9CasAT0oD AFFKAwBeSgMADQAIAAABCAAAAggAAEsIAACUCAAA3QgAACYJAABvCQAAuAkAAAEKAABKCgAA SwoAAEwKAACQCgAAxwoAAMgKAADRCgAA0goAABYLAABUCwAAkwsAANMLAAAbDAAAWQwAAJYM AACXDAAArQwAAK4MAAD1DAAAPQ0AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAdPQ0AAIMNAACEDQAAmA0AAJkN AADaDQAA/g0AAP8NAABEDgAAhg4AAM4OAAALDwAADA8AAFUPAACdDwAA3w8AAB0QAAAeEAAA VRAAAFYQAABnEAAAaBAAAGkQAABqEAAAaxAAALQQAAC2EAAA/xAAAAARAAABEQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2TIFhAAAB0BEQAARBEAAG8RAABwEQAAsREAANoRAAAdEgAAXRIAAKYSAADuEgAANBMAAHcT AACjEwAApBMAAKUTAAC3EwAAuBMAAAEUAABKFAAAkxQAANwUAAAlFQAAbhUAALcVAAAAFgAA SRYAAJIWAADbFgAAJBcAAG0XAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHW0XAAC2FwAA/xcAAEgYAACRGAAA 2hgAACMZAABsGQAAtRkAAP4ZAABHGgAAkBoAAJEaAACSGgAAkxoAAJQaAACVGgAAlhoAAJca AACYGgAAmRoAAJoaAACbGgAA5BoAAOYaAAAvGwAAMBsAADEbAABCGwAAQxsAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk yBYQAAAdQxsAAIwbAADSGwAAFRwAAF0cAACEHAAAhRwAAMwcAAAOHQAAVR0AAJodAADjHQAA LB4AAHIeAAC5HgAAAB8AADYfAABUHwAAVR8AAJQfAADaHwAAHSAAAGQgAACrIAAA7yAAAB0h AAAeIQAAZiEAAK4hAAD1IQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB31IQAAPCIAAHAiAABxIgAAuiIAAAAj AABJIwAAiCMAAM8jAAAWJAAATyQAAFAkAACXJAAAmCQAAN4kAAANJQAADiUAAA8lAAAQJQAA ESUAABIlAABbJQAAXSUAAKYlAACnJQAAqCUAAPAlAAA2JgAAfyYAALMmAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgW EAAAHbMmAAC0JgAAACcAAEknAAB+JwAAfycAAMMnAAAIKAAACSgAAAooAAAXKAAAGCgAAF4o AACkKAAA5SgAACUpAABrKQAAkykAAJQpAACVKQAAsCkAALEpAADNKQAAzikAABUqAABbKgAA oyoAAOIqAAAqKwAAcysAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAdcysAALwrAADnKwAA6CsAACssAAAsLAAA dSwAALQsAAD2LAAAPS0AAIUtAACtLQAAri0AAPQtAAA0LgAAci4AAHMuAAB0LgAAdS4AAL4u AADALgAACS8AAAovAAALLwAASy8AAI8vAACQLwAA2C8AAB8wAABmMAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAA AB1mMAAAqjAAAMowAADLMAAAEjEAAFkxAACcMQAAuDEAALkxAAD/MQAAQjIAAHgyAAB5MgAA vzIAAAUzAAAnMwAAKDMAAHEzAAC1MwAA/DMAAD40AACGNAAAmTQAAJo0AADeNAAAJzUAAGo1 AACvNQAA8DUAABg2AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHRg2AAAZNgAAXzYAAKM2AADkNgAAKTcAAEQ3 AABFNwAAaTcAAGo3AACvNwAA+DcAACk4AAAqOAAAKzgAACw4AAAtOAAAdjgAAHg4AADBOAAA wjgAAMM4AAAHOQAATjkAAJQ5AADaOQAAIToAAGY6AACrOgAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2Q9CasAAAQPAGdkyBYQAAAc qzoAAPE6AAA3OwAAYzsAAGQ7AACoOwAA8DsAADM8AABVPAAAVjwAAIM8AACEPAAAkDwAAMM8 AAD7PAAAJT0AAE49AABlPQAAZj0AAKk9AADePQAA3z0AAP89AAAAPgAARj4AAI0+AADUPgAA Gj8AAGM/AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEDwBnZMgWEAAABA8AZ2Q9CasAABxjPwAAnT8AAN8/AAAmQAAAb0AAAIlAAACKQAAA 0EAAABdBAABfQQAAn0EAAOhBAAAsQgAAbUIAAG5CAABvQgAAcEIAALlCAAC7QgAABEMAAAVD AAAGQwAAT0MAAJRDAADVQwAAGkQAAGBEAAB2RAAAd0QAAL9EAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHb9E AAAFRQAATEUAAJNFAADcRQAAJUYAAGxGAACqRgAA2EYAANlGAAARRwAAEkcAAB5HAABGRwAA eUcAAKJHAADURwAAGkgAAC5IAAAvSAAATUgAAE5IAACKSAAAi0gAALJIAACzSAAAykgAAMtI AADoSAAA6UgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAd6UgAAAhJAAAJSQAASUkAAJFJAADTSQAAG0oAADpK AAA7SgAAPEoAAD1KAAA+SgAAP0oAAEBKAABBSgAAikoAAIxKAADVSgAA1koAANdKAAAcSwAA ZEsAAKpLAADwSwAAN0wAAHtMAADCTAAABE0AAExNAACUTQAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB2UTQAA 3U0AAOlNAADqTQAAME4AAHROAAC6TgAA/U4AAEVPAACKTwAAzU8AAAtQAABMUAAAlVAAANpQ AAAiUQAAZ1EAAJNRAACUUQAA3VEAACVSAABpUgAAslIAAPJSAAA3UwAAgFMAAMNTAAD6UwAA +1MAAEJUAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZMgWEAAAHUJUAACFVAAAzVQAABNVAABTVQAAmVUAAOBVAAApVgAA klYAAM9WAADQVgAA0VYAANJWAAAbVwAAHVcAAGZXAABnVwAAaFcAALFXAAD4VwAAP1gAAIVY AADFWAAACVkAAE9ZAACTWQAAlFkAAN1ZAAAmWgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2TcOjcAAAQPAGdkyBYQAAAcGlYAABtW AAAwVgAAVVYAAHViAAB2YgAA9HUAAPV1AAA7dwAAR3cAAEh3AABTdwAAWHcAAFl3AABddwAA /YAAAP6AAABVgQAA+4QAAOLGtqmbqY2pcWFOcWFOqUAwqQAAHwEIgQRIAQAFaJVaI0cWaPoY 5wBPSgMAUUoDAF5KAwAbA2oAAAAAFmj6GOcAMEoRAE9KBABRSgQAVQgBJQEIgQRIAQAFaJNa I0cVaMgWEAAWaKNrcgBPSgMAUUoDAF5KAwAfAQiBBEgBAAVok1ojRxZoo2tyAE9KAwBRSgMA XkoDADcACIEVaMgWEAAWaD0JqwAXaKNrcgBPSgMAUUoDAF5KAwBjSAEAZGgAAAAAZGgAAAAA ZGiTWiNHGwNqAAAAABZo9RLbADBKEQBPSgQAUUoEAFUIARsDagAAAAAWaEATFgAwShEAT0oE AFFKBABVCAEYFWjIFhAAFmg9CasAT0oDAFFKAwBeSgMAAB8BCIEESAEABWiJWiNHFmjcOjcA T0oDAFFKAwBeSgMANwAIgRVoyBYQABZoPQmrABdo3Do3AE9KAwBRSgMAXkoDAGNIAQBkaAAA AABkaAAAAABkaIlaI0c6AAiBA2oAAAAAFmjcOjcAF2jcOjcAMEoRAE9KBABRSgQAVQgBY0gB AGRoAAAAAGRoAAAAAGRoiVojRxImWgAAbVoAALVaAAD2WgAAMlsAADNbAABzWwAAu1sAAARc AABMXAAAi1wAANFcAAAVXQAAXl0AAKBdAADmXQAALl4AAHVeAAC1XgAA/F4AADlfAAB+XwAA xV8AAAtgAABPYAAAkWAAANBgAADRYAAAGWEAAGJhAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHWJhAACqYQAA 02EAANRhAAAdYgAAZGIAAK5iAAD0YgAAO2MAADxjAAA9YwAAPmMAAIdjAACJYwAA0mMAANNj AADUYwAAHGQAAGVkAACuZAAA92QAAD5lAACEZQAAyGUAABBmAAAiZgAAI2YAAFRmAABVZgAA YWYAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkyBYQAAAdYWYAAIxmAADBZgAA8GYAABtnAAA0ZwAANWcAADZnAABCZwAA a2cAAJhnAADKZwAA+GcAAApoAAALaAAADGgAABhoAABFaAAAeWgAAKhoAAC+aAAAv2gAAMBo AADMaAAA/mgAADlpAABRaQAAUmkAAFNpAABfaQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB1faQAApWkAAOZp AAAAagAAAWoAAAJqAAADagAABGoAAAVqAAAGagAAT2oAAFFqAACaagAAm2oAAJxqAACoagAA 22oAACNrAABsawAAqWsAAN1rAAAebAAAX2wAAJdsAADcbAAA9WwAAPZsAAAZbQAAGm0AAF1t AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZMgWEAAAHV1tAAClbQAA7G0AAC1uAABwbgAAtW4AAP1uAABGbwAAjm8AANRv AAAacAAAY3AAAHpwAAB7cAAAvHAAANVwAADWcAAAGXEAAGFxAAChcQAA5nEAAPpxAAD7cQAA KHIAAClyAABKcgAAS3IAAIVyAACGcgAAyXIAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAdyXIAAMpyAAD0cgAA 9XIAAPZyAAD3cgAA+HIAAPlyAABCcwAARHMAAI1zAACOcwAAj3MAAL1zAAC+cwAA/HMAABV0 AAAWdAAAXnQAAF90AACodAAAzXQAAM50AAAEdQAABXUAADV1AAA2dQAAc3UAAHR1AACTdQAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2TIFhAAAB2TdQAAlHUAALR1AAC1dQAA9HUAAPZ1AAAndgAAKHYAAEt2AABMdgAA d3YAAHh2AACsdgAArXYAAPZ2AAA4dwAAkHcAAJ93AACgdwAAyncAAMt3AADXdwAAA3gAADF4 AABZeAAAiHgAAJl4AACaeAAAm3gAAJx4AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHZx4AACdeAAAnngAAJ94 AACgeAAAoXgAAOp4AADseAAANXkAADZ5AAA3eQAAX3kAAGB5AACmeQAA7nkAADd6AAB2egAA vHoAAPd6AAD4egAAIXsAACJ7AAAuewAAVnsAAH97AACnewAAz3sAAPd7AAAnfAAAKHwAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkyBYQAAAdKHwAAFh8AACDfAAAs3wAAOV8AADmfAAAIn0AADZ9AAA3fQAAOH0AAER9 AAByfQAAoH0AANh9AAAKfgAARn4AAH9+AAC7fgAA0n4AANN+AADUfgAA4H4AAA5/AABCfwAA Wn8AAFt/AABcfwAAXX8AAF5/AABffwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB1ffwAAYH8AAGF/AABifwAA q38AAK1/AAD2fwAA938AAPh/AAAUgAAAFYAAAFeAAACcgAAA4IAAAFaBAABXgQAAnoEAAOeB AAAsggAAc4IAALGCAAD4ggAANoMAAGGDAABigwAApIMAAOSDAAAohAAAcIQAALaEAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZMgWEAAAHfuEAAD8hAAAgYUAAIKFAABcjAAAYYwAAGiMAAAjkAAAJJAAAPiTAAABlAAA DpQAAA+UAADKuAAAy7gAAMy4AADbuAAA3LgAABK7AADx5NbkuqrknOSAcF3kU0lFOzcAAAAA AAAAAAAAAAAAAAAABhZoED3QAAATA2oAAAAAFmgQPdAAMEoRAFUIAQYWaIUN0AAAEwNqAAAA ABZohQ3QADBKEQBVCAESFmjIFhAAT0oDAFFKAwBeSgMAACUBCIEESAEABWi7WiNHFWjIFhAA Fmh+PNoAT0oDAFFKAwBeSgMAHwEIgQRIAQAFaLtaI0cWaH482gBPSgMAUUoDAF5KAwA3AAiB FWjIFhAAFmg9CasAF2h+PNoAT0oDAFFKAwBeSgMAY0gBAGRoAAAAAGRoAAAAAGRou1ojRxsD agAAAAAWaH482gAwShEAT0oEAFFKBABVCAEfAQiBBEgBAAVouFojRxZofjzaAE9KAwBRSgMA XkoDADcACIEVaMgWEAAWaD0JqwAXaH482gBPSgMAUUoDAF5KAwBjSAEAZGgAAAAAZGgAAAAA ZGi4WiNHGwNqAAAAABZo0VyXADBKEQBPSgQAUUoEAFUIARgVaMgWEAAWaD0JqwBPSgMAUUoD AF5KAwAAGwNqAAAAABZoFVQLADBKEQBPSgQAUUoEAFUIAQAStoQAAP2EAABFhQAAZIUAAGWF AACshQAA74UAADiGAAB+hgAAwoYAAAiHAABNhwAAcIcAAHGHAAC3hwAAAIgAADOIAAA0iAAA U4gAAFSIAABgiAAAi4gAALuIAADriAAAH4kAAFGJAABliQAAZokAAGeJAABoiQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2TIFhAAAB1oiQAAaYkAALKJAAC0iQAA/YkAAP6JAAD/iQAAC4oAAD2KAAB9igAAs4oAAMyK AADNigAAzooAANqKAAAMiwAASIsAAIKLAACaiwAAm4sAAOSLAAALjAAADIwAABuMAAAcjAAA aYwAAKyMAAD0jAAAO40AAIONAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHYONAADKjQAAEo4AAFKOAABojgAA aY4AALCOAAD5jgAAPY8AAIWPAADMjwAAFJAAAFmQAACikAAA5pAAAC2RAAB0kQAAuZEAAAGS AABEkgAAUZIAAFKSAACXkgAA35IAACeTAABckwAAXZMAAF6TAABfkwAAqJMAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk yBYQAAAdqJMAAKqTAADzkwAA9JMAAPWTAABIlAAAkZQAANWUAADslAAA7ZQAADGVAABZlQAA opUAAOqVAAAxlgAAQJYAAEGWAABClgAATpYAAHqWAAColgAA25YAAAmXAABAlwAAd5cAAKSX AADmlwAA+5cAAPyXAAAVmAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB0VmAAAFpgAAF6YAACHmAAAiJgAAMaY AADamAAA25gAACGZAABOmQAAT5kAAI6ZAACPmQAAwpkAAMOZAAAEmgAASpoAAF6aAABfmgAA pZoAAO6aAAAhmwAAIpsAACObAAAkmwAAJZsAACabAABvmwAAcZsAALqbAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgW EAAAHbqbAAC7mwAAvJsAAMibAAD0mwAAApwAADGcAABgnAAAjpwAAL6cAADGnAAA+JwAAAyd AAANnQAAJZ0AACadAABFnQAARp0AAFKdAACZnQAA4Z0AACKeAAA4ngAAOZ4AAFGeAABSngAA mZ4AAN2eAAAgnwAAYp8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAdYp8AAKefAADgnwAA4Z8AACCgAABkoAAA q6AAAO6gAAAzoQAAe6EAAMGhAADZoQAA2qEAAPmhAAD6oQAA+6EAAPyhAAD9oQAA/qEAAP+h AAAAogAAAaIAAAKiAAADogAABKIAAE2iAABPogAAmKIAAJmiAACaogAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAA AB2aogAApqIAAOuiAAAxowAAeqMAAMKjAAALpAAAVKQAAJ2kAADWpAAAFKUAACqlAAArpQAA QqUAAEOlAABipQAAY6UAAG+lAACbpQAAsKUAALGlAADKpQAAy6UAABSmAABXpgAAWKYAAGSm AACIpgAAn6YAAKCmAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHaCmAAC6pgAAu6YAAASnAABMpwAAjqcAANan AAAZqAAAXagAAKWoAADqqAAAAKkAAAGpAAAgqQAAIakAAC2pAABkqQAAmakAAM6pAAD/qQAA AKoAAAGqAAACqgAAS6oAAE2qAACWqgAAl6oAAJiqAACwqgAAsaoAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAd saoAALKqAADKqgAAy6oAAPaqAAD3qgAAP6sAAEerAABIqwAASasAAGWrAABmqwAArasAAPSr AAAyrAAAcKwAALSsAAD7rAAAN60AAH+tAADArQAA/q0AAEOuAACIrgAAya4AABCvAABWrwAA nq8AAK2vAACurwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB2urwAAr68AAMSvAADFrwAADLAAAB6wAAAfsAAA YLAAAKOwAADrsAAAI7EAACSxAAAlsQAANLEAADWxAAA2sQAAN7EAADixAAA5sQAAOrEAADux AACEsQAAhrEAAM+xAADQsQAA0bEAAOyxAADtsQAAL7IAAHCyAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZMgWEAAAHXCy AABxsgAAs7IAAO2yAADusgAAC7MAAAyzAAAvswAAeLMAALmzAAD+swAAF7QAABi0AAA1tAAA eLQAAL60AADrtAAAKrUAAEa1AABHtQAAj7UAAMy1AADotQAA6bUAAOq1AAD9tQAA/rUAABK2 AAAltgAASLYAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkyBYQAAAdSLYAAF62AABwtgAAcbYAAHK2AACEtgAAl7YAALq2 AADQtgAA4rYAAOO2AADktgAA5bYAAOa2AADntgAA6LYAAOm2AADqtgAA67YAADS3AAA2twAA f7cAAIC3AACBtwAAlLcAALi3AADOtwAA6rcAAPO3AAD0twAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAB30twAA 9bcAAA64AAAquAAAO7gAAE64AABZuAAAWrgAAFu4AABcuAAAXbgAAF64AABfuAAAYLgAAGG4 AABiuAAAY7gAAGS4AABluAAAZrgAAGe4AABouAAAabgAAGq4AABruAAAbLgAAG24AABuuAAA b7gAAHC4AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZMgWEAAAHXC4AABxuAAAcrgAAHO4AAB0uAAAdbgAAHa4AAB3uAAA eLgAAHm4AAB6uAAAe7gAAHy4AAB9uAAAfrgAAH+4AACAuAAAybgAAMu4AADbuAAAoLoAAKG6 AAASuwAAFrwAAJW8AADavAAA27wAAPK8AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAA AAAAAAAACBIACiYAC0YBAGdk9RLbAAAEEgBnZBA90AAAARIAAAQPAGdkyBYQAAAbErsAABO7 AAAWvAAAF7wAAJW8AACWvAAA8rwAAPO8AAA5vQAAOr0AAKO9AACkvQAA/r0AAP+9AAA4vgAA Ob4AAPXx5+PZ1cvHvbmvq6GdkwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEhZoyBYQAE9KAwBRSgMAXkoDAAAGFmh+PNoAABMDagAAAAAW aH482gAwShEAVQgBBhZo0VyXAAATA2oAAAAAFmjRXJcAMEoRAFUIAQYWaBVUCwAAEwNqAAAA ABZoFVQLADBKEQBVCAEGFmj6GOcAABMDagAAAAAWaPoY5wAwShEAVQgBBhZo9RLbAAATA2oA AAAAFmj1EtsAMEoRAFUIAQYWaEATFgAAEwNqAAAAABZoQBMWADBKEQBVCAEGFmjcOjcAABMD agAAAAAWaNw6NwAwShEAVQgBAA/yvAAAOb0AAKO9AAD+vQAAN74AADi+AAA5vgAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2TIFhAAAAEAAAABEgAABjIAMZBoATpw Y1CLAB+w0C8gsOA9IbDaBSKw2gUjkPADJJDwAyWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGoEGAASAAEACwEPAAcABAAEAAQAAAAEAAgAAACYAAAAngAAAJ4AAACeAAAA ngAAAJ4AAACeAAAAngAAAJ4AAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA+AgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAAuAAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAAGgBAABIAQAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AACwAwAANgYAADIGAAAYAAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAA UAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgB AADoAQAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAA AAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPAD AAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA 8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOAD AADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA 4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAOAEAAFgB AAD4AQAACAIAABgCAABWAgAAfgIAACAAAABPSgQAUEoEAFFKBABfSAEEbUgJBG5ICQRzSAkE dEgJBAAAAABGAABg8f8CAEYADBAAAN8hbwAAAAYATgBvAHIAbQBhAGwAAAAIAAAAEmQUAQEA GABDShYAX0gBBGFKFgBtSAkEc0gJBHRICQQAAAAAAAAAAAAAAAAAAAAAAABEAEFg8v+hAEQA DA0AAAAAAAAQABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4A dAAAAAAAUgBpAPP/swBSAAwdAAAAAAAAMAYMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAA HAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAA MAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAEYAWkABAPIARgAMDBAAyBYQADAGCgBQAGwA YQBpAG4AIABUAGUAeAB0AAAACAAPABJk8AABABAAQ0oVAE9KBQBRSgUAYUoVAEYA/g+iAAEB RgAMAA8AyBYQADAGDwBQAGwAYQBpAG4AIABUAGUAeAB0ACAAQwBoAGEAcgAAABAAQ0oVAE9K BQBRSgUAYUoVAEIAJ0CiABEBQgAMDQAAhQ3QADAGEQBDAG8AbQBtAGUAbgB0ACAAUgBlAGYA ZQByAGUAbgBjAGUAAAAIAENKEABhShAAPAAeQAEAIgE8AAwNEwCFDdAAMAYMAEMAbwBtAG0A ZQBuAHQAIABUAGUAeAB0AAAAAgASAAgAQ0oUAGFKFAA6AP4PogAxAToADAESAIUN0AAwBhEA QwBvAG0AbQBlAG4AdAAgAFQAZQB4AHQAIABDAGgAYQByAAAAAABAAGoAIQEiAUAADA0VAIUN 0AAwBg8AQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAAAACABQABgA1CIFcCIFGAP4P MgFRAUYADAEUAIUN0AAwBhQAQwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAIABDAGgA YQByAAAABgA1CAFcCAFOAJkAAQBiAU4ADA0XAIUN0AAwBgwAQgBhAGwAbABvAG8AbgAgAFQA ZQB4AHQAAAAIABYAEmTwAAEAFABDShAAT0oGAFFKBgBeSgYAYUoQAE4A/g+iAHEBTgAMARYA hQ3QADAGEQBCAGEAbABsAG8AbwBuACAAVABlAHgAdAAgAEMAaABhAHIAAAAUAENKEABPSgYA UUoGAF5KBgBhShAAUEsDBBQABgAIAAAAIQCCirwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlw ZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqJJd30s0g8Y5LEtao+ENAnJ33fsuFC6CC10 IxBizpl7Va6P46AOGJPzVOlVXmiFZH3jqKv0++4pu9cqMVADgyes9AmTXtfXV+XuFDApmaZU 6Z45PBiTbI8jpNwHJHlpfRyB5Ro7E8B+QIfmtijujPXESJzxxNB1+SoLRNegeoPILzCKx7Cg 8Pv5DCSAmAtYq8czYVqi0hDC4CywRDAHan7oM9+2zmLj7X4UaT6DF9jNBDO/XGD1P+ov5wZb 2A+stkfp4lx/xCH9LdtSay6Tc/7Uu5AuGC6Xt7Rh5r+tPwEAAP//AwBQSwMEFAAGAAgAAAAh AKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLDGCV2L6WQQy+j fQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUI W3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2 TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA //8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFu YWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtL DVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh 7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQ GwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZst TRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiK rT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN 99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08 lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDD UsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpB zwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZ wRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaC aCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9 D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZ xv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNx vhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LYAe5y zjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yA kArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArM KoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+ y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtP rwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPld hDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPG BmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcol HOzMcCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbX Qp2ZW92IZkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+ 0nrP+6hunJTHirkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqSc nCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zC Th1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ua lVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTP ZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE /b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5L kmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unO xyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObdaW7HmNF5u5sKB F+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2THbTBpElZ 02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHGOMZ8 0ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAh AA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJl bHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My 3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5 gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUo osbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQCCirwT+gAAABwCAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fA AAAANgEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5 lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54 bWxQSwECLQAUAAYACAAAACEAlrWt4pYGAABQGwAAFgAAAAAAAAAAAAAAAADRAgAAdGhlbWUv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAA AAAAAJsJAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAA AAUABQBdAQAAlgoAAAAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0 YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9w ZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJk azEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNj ZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNj ZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxp bmsiLz4UAEMAZQBuAHQAdQByAHkATABpAG4AawAgAEUAbQBwAGwAbwB5AGUAZQBQIAAAwzIA ABpOAAB1WgAA9G0AAP14AAD7fAAAgX0AACOIAAA5tgAAAgBDAEMAAAAAAAAAAAAAAAAAAAAA AAAAAABdRckWAgBDAEMAAAAAAAAAAAAAAAAAAAAAAAAAAADpXckWAgBDAEMAAAAAAAAAAAAA AAAAAAAAAAAAAADKXskWAgBDAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAuYMkWAgBDAEMAAAAA AAAAAAAAAAAAAAAAAAAAAAD/////AgBDAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAD1YckWAgBD AEMAAAAAAAAAAAAAAAAAAAAAAAAAAACyYskWAgBDAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAi Y8kWAgBDAEMAAAAAAAAAAAAAAAAAAAAAAAAAAACxaskWElojRwAAAAAAAAAAAAAAAAAAg1oj RwAAAAAAAAAAAAAAAAAAiVojRwAAAAAAAAAAAAAAAAAAjlojRwAAAAAAAAAAAAAAAAAAk1oj RwAAAAAAAAAAAAAAAAAAlVojRwAAAAAAAAAAAAAAAAAAmVojRwAAAAAAAAAAAAAAAAAAmloj RwAAAAAAAAAAAAAAAAAAulojRwAAAAAAAAAAAAAAAAAAAAAAABAAAABHAgAASwMAAMoDAAAn BAAAbgQAANgEAAAzBQAAbAUAAG8FAAAAAAAAObYAAA8AABwBAAAA/////wAIAAAaVgAA+4QA ABK7AAA5vgAAYAAAAHEAAAB8AAAAjAAAAAAIAAA9DQAAAREAAG0XAABDGwAA9SEAALMmAABz KwAAZjAAABg2AACrOgAAYz8AAL9EAADpSAAAlE0AAEJUAAAmWgAAYmEAAGFmAABfaQAAXW0A AMlyAACTdQAAnHgAACh8AABffwAAtoQAAGiJAACDjQAAqJMAABWYAAC6mwAAYp8AAJqiAACg pgAAsaoAAK6vAABwsgAASLYAAPS3AABwuAAA8rwAADm+AABhAAAAYgAAAGMAAABkAAAAZQAA AGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcgAAAHMAAAB0 AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAA AIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAI0AAAAPAADwOAAAAAAABvAY AAAAAggAAAIAAAABAAAAAQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8A AvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4A AAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wgACgAAAAAB XUXJFv////8AAAAB6V3JFv////8AAAAByl7JFv////8AAAABLmDJFv////8AAAAB9WHJFv// //8AAAABsmLJFv////8AAAABImPJFv////8AAAABsWrJFv////9KIAAAZjIAABJOAAD0WQAA lngAAMh8AABofQAAA4gAAM2wAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAFAg AADDMgAAGk4AAHVaAAD9eAAA+3wAAIF9AAAjiAAAzbAAAAAAAAAeAQAAJQEAAKoBAAC3AQAA eQcAAIIHAAA8FwAAQhcAAEMXAABHFwAANhwAAEAcAACsHAAAuxwAAEogAABQIAAAdCIAAHoi AAB7IgAAfyIAAKI0AAClNAAA1TQAANg0AAAtNQAAMTUAAFY1AABfNQAAYDUAAGM1AAAlPwAA KT8AAFg/AABbPwAAqT8AALA/AADbPwAA3j8AACJAAAAoQAAAKUAAACxAAACARgAAiUYAAIpG AACORgAAOUcAAERHAABOVwAAUVcAAA5YAAAXWAAA1FgAAOFYAABwXgAAc14AAJ5eAAChXgAA 1F4AANdeAAAGXwAACV8AAC9fAAAyXwAABWAAAAhgAABPYAAAVGAAAFpgAABdYAAAimAAAI1g AAC5YAAAvGAAAAhhAAANYQAAFWEAABhhAABBYQAARmEAAExhAABPYQAAZmEAAGlhAADuYQAA 82EAAPthAAD+YQAAr2IAALZiAADiYgAA6mIAACpjAAAyYwAA8GQAAPNkAAC/agAAx2oAAJtu AACqbgAA3m8AAOJvAAAKcAAAEnAAAJRwAACXcAAANXMAADlzAAALdAAADnQAAC90AAA3dAAA X3QAAGd0AACKdAAAknQAALp0AADCdAAA+3QAAP50AAAxdQAANHUAAKd1AACqdQAAEXYAABN2 AAAydgAANHYAAE12AABPdgAAhnYAAIh2AACndgAAqnYAAM12AADQdgAAVXcAAFh3AAB4fwAA gH8AAGeAAABvgAAAkoAAAJaAAAD9gAAAAIEAADWBAAA4gQAAYIEAAGOBAAAaggAAHYIAADWC AAA7ggAAkoIAAJWCAADHggAAyoIAAOGCAADpggAAE4MAABaDAACVgwAAmIMAAK2DAACwgwAA +IsAAA6MAACBjgAAhI4AAOyOAADvjgAAR48AAE6PAAD2jwAA+Y8AAGaSAABukgAAGJQAABuU AABHlAAASpQAAHWUAAB4lAAApZQAAKiUAADblAAA3pQAAAeVAAAKlQAAWZUAAGGVAACglQAA qJUAAOiVAADrlQAAM5YAADaWAACAmAAAiJgAAFiZAABgmQAAfpkAAIeZAACcmQAApJkAAK2a AAC1mgAA8poAAPqaAAA4mwAAO5sAAMmbAADMmwAAEpwAABWcAABbnAAAXpwAAKScAACnnAAA xJwAAMycAAAEnQAADJ0AACWdAAAonQAAdp0AAH6dAACrnQAArp0AAJqeAACdngAAa6EAAG6h AACgoQAAo6EAANWhAADYoQAAq6IAAK6iAABMqAAAU6gAAFioAABfqAAAY6gAAHCoAADhqAAA 6qgAAPupAAACqgAAf6oAAISqAAASqwAAG6sAAByrAAAgqwAAPasAAESrAAAerAAAJKwAACWs AAAprAAAXKwAAGOsAACGrAAAjKwAAJmsAACfrAAAVa0AAFmtAABlrQAAcq0AACiuAAAwrgAA N64AAEGuAACargAAoq4AAKmuAACzrgAAjK8AAJOvAAD4rwAA/68AAACwAAANsAAAy7AAADq2 AAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcABAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAAAAAAogIAAMYCAAAZAwAA OgMAAFcDAABiAwAAlgMAAKQDAADWAwAA3wMAAB4EAAAmBAAAXAQAAGcEAABABQAASAUAAN0F AADnBQAAiQYAAJAGAADRBgAA2gYAAFgHAABbBwAAoAcAAKQHAADiBwAA6gcAAGsIAAB8CAAA RwkAAE8JAAAgCgAAKwoAAGAKAABpCgAAqQoAAKsKAADxCgAA+AoAADcLAAA6CwAAegsAAIML AACbDAAAqQwAAOQMAADqDAAALQ0AAD0NAAB2DQAAhA0AAL8NAADEDQAACA4AABUOAABRDgAA XQ4AAJoOAAClDgAA4w4AAOwOAAAwDwAAOw8AAHkPAACEDwAAwg8AAMgPAAALEAAAFxAAAFQQ AABdEAAAvREAAMkRAAAGEgAAFBIAAJsSAACsEgAAjxMAAJMTAADVEwAA2xMAABgUAAAjFAAA YBQAAIMUAABYFQAAWxUAAJ0VAAChFQAA5hUAAOkVAAB1FgAAeRYAALwWAADHFgAAAxcAAAUX AAA5FwAAUxcAAJcXAACgFwAAIBgAACcYAACuGAAAuRgAAPIYAAD/GAAAaRkAAGwZAACxGQAA uRkAAPgZAAD7GQAAPxoAAEgaAAC9GgAAvhoAAAMbAAAOGwAATBsAAFQbAACLGwAAlhsAANIb AADdGwAAGRwAACAcAADlHAAA7RwAABIdAAAjHQAA9x0AAPodAAA9HgAARx4AAIYeAACRHgAA Bx8AAAofAABQHwAAXR8AAMofAADPHwAAYSAAAGcgAACnIAAArCAAAOggAADxIAAAKCEAADEh AABuIQAAdCEAALQhAADCIQAAGCIAACAiAABeIgAAYSIAAKYiAACoIgAALSMAADMjAAB2IwAA fCMAAL8jAADDIwAAuyQAAMUkAABEJQAATyUAAIwlAACTJQAA+yUAAAcmAAA7JgAASCYAAHUm AACGJgAAEicAAB0nAABSJwAAjicAAN8nAADjJwAAJigAADMoAABtKAAAdCgAALEoAAC8KAAA YCkAAGopAACjKQAArCkAAAYqAAAMKgAASSoAAFUqAADGKgAAySoAAAwrAAARKwAAdCsAAHcr AAC4KwAAwSsAAP8rAAABLAAAQSwAAEksAACJLAAAiywAAOEsAADmLAAAKi0AADQtAABtLQAA di0AALItAAC/LQAA8y0AAP4tAABiLgAAaS4AAKYuAACzLgAA5y4AAO8uAAAsLwAAMi8AAEgv AABOLwAAsi8AALwvAAD7LwAA/C8AAC0wAAA+MAAACjEAABExAABRMQAAVjEAAJcxAACgMQAA 3TEAAOAxAAAkMgAAJzIAAPQyAAD5MgAAOjMAAEMzAAA2NAAAQDQAAIc0AACNNAAAlzQAAKU0 AADKNAAA2DQAAAM1AAAGNQAALTUAADE1AACsNQAAsjUAAOI1AADyNQAASTYAAEw2AACQNgAA kjYAANc2AADaNgAAHTcAACc3AABmNwAAaDcAAKA3AACvNwAA4jcAAOs3AAApOAAAMTgAAHI4 AACIOAAA0zgAANk4AAAaOQAAITkAAGI5AABkOQAAojkAAKw5AADrOQAA7jkAAC86AAA1OgAA cDoAAIE6AAAJOwAAETsAAFI7AABUOwAAlzsAAJ47AADYOwAA4TsAAB08AAAmPAAAYzwAAGk8 AADCPAAAxTwAAAg9AAAMPQAAlj0AAJg9AADfPQAA4j0AACg+AAAqPgAAbz4AAHI+AACtPgAA uD4AABU/AAAbPwAAJT8AACk/AABNPwAAWz8AAIA/AACGPwAAqT8AALA/AADbPwAA3j8AADJA AABAQAAATEEAAFZBAACUQQAAm0EAANZBAADeQQAAHkIAACBCAABBQgAAUkIAACJDAABNQwAA sEMAALNDAAD2QwAA/kMAAD1EAABARAAAgUQAAIdEAADIRAAAy0QAAApFAAARRQAAU0UAAFdF AACaRQAAnUUAAONFAADnRQAAM0YAADZGAAB3RgAAfEYAAL1GAADCRgAAAEcAAApHAABIRwAA T0cAAI1HAACSRwAA0EcAANdHAACYSAAAm0gAAN1IAAD7SAAAJUkAACdJAABqSQAAcUkAAChK AAAqSgAAtUoAALtKAAD1SgAA/koAADpLAABCSwAAg0sAAIVLAADGSwAAz0sAAEVMAABHTAAA iEwAAI5MAADQTAAA2UwAABZNAAAcTQAAVk0AAGFNAADjTQAA7k0AADBOAAA5TgAAlU4AAJxO AADSTgAA404AALRPAAC3TwAA+08AAP1PAABCUAAAS1AAAIhQAACQUAAAyFAAANFQAAAMUQAA ElEAAFJRAABWUQAAc1IAAHpSAAC7UgAAwVIAAPxSAAAxUwAAvlMAAMBTAAAHVAAACVQAAE9U AABXVAAAjlQAAJlUAADUVAAA3FQAABhVAAAiVQAAYVUAAGpVAACjVQAAqlUAAHhWAACCVgAA 4VYAAONWAAD/VgAACFcAADxXAABKVwAAyFcAAM9XAAAOWAAAF1gAAFJYAABYWAAAZVkAAGhZ AACtWQAAs1kAACBaAAAkWgAAZ1oAAGxaAACxWgAAtFoAAPdaAAD9WgAAPlsAAE9bAADXWwAA 21sAAB9cAAAiXAAAaFwAAGpcAACxXAAAtFwAAPpcAAD9XAAAh10AAItdAAATXgAAGV4AAFhe AABeXgAAaF4AAHNeAACTXgAAoV4AAMheAADXXgAABl8AAA1fAAA5XwAAP18AAElfAABPXwAA cl8AAHVfAACfXwAApV8AANFfAADXXwAAD2AAABVgAAAfYAAAJWAAAExgAABdYAAAgGAAAI1g AADDYAAAyWAAANNgAADZYAAABWEAABhhAABWYQAAXGEAAGZhAABpYQAArGEAALJhAAAGYgAA F2IAAJ9iAAClYgAAr2IAALZiAADiYgAA6mIAACpjAAAyYwAAc2MAAHljAAAlZAAAK2QAAPlk AAD+ZAAAYGUAAI9lAACoZQAAs2UAAO9lAAD2ZQAAMGYAADtmAABzZgAAeWYAAABnAAADZwAA SWcAAFBnAACRZwAAm2cAAB1oAAAgaAAAZmgAAHloAAC/aAAAyGgAACBpAAAnaQAAaGkAAGtp AACoaQAAtWkAAAJqAAAGagAAMGoAADRqAABSagAAVmoAAI1qAACRagAA0WoAANVqAAD5agAA CmsAAJZrAACaawAAxWsAAMlrAAAdbAAAIWwAAGZsAABqbAAAsmwAALRsAAAMbQAAEG0AAD1t AABBbQAAe20AAH9tAACbbQAAn20AALxtAADAbQAAL24AADNuAABTbgAAV24AAH9uAACDbgAA +W4AAABvAABHbwAAZm8AAJNvAACdbwAAzm8AANRvAADebwAA4m8AAApwAAAScAAAOHAAADxw AABgcAAAZnAAAKFwAACycAAAOnEAAEdxAACpcQAAtHEAADpyAAA+cgAAeXIAAIRyAAC/cgAA w3IAACVzAAArcwAANXMAADlzAABdcwAAYHMAAIZzAACMcwAArnMAALRzAADWcwAA3HMAAP5z AAAOdAAAL3QAADd0AABfdAAAZ3QAAIp0AACSdAAAunQAAMJ0AADtdAAA/nQAADt1AABBdQAA S3UAAFF1AAB5dQAAf3UAAKd1AACqdQAA33UAAOV1AAARdgAAG3YAAE12AABXdgAAhnYAAJB2 AADXdgAA3XYAAOd2AADqdgAAFXcAABt3AABidwAAc3cAAPt3AAAHeAAAWngAAGV4AACfeAAA qngAAON4AADoeAAAoXkAAKN5AADqeQAA7nkAAC96AAAzegAAdnoAAHt6AAD7egAAAHsAADl7 AABEewAAp3sAAK17AADnewAA8nsAACt8AAA1fAAAuXwAAMZ8AAAAfQAAA30AAEh9AABPfQAA r30AALh9AADyfQAA/X0AADt+AABBfgAAxX4AANJ+AAALfwAAEn8AAFB/AABWfwAAA4AAADKA AABXgAAAXYAAAGeAAABvgAAAkoAAAJaAAADCgAAAyIAAAPKAAAAAgQAANYEAADyBAABpgQAA eoEAAAKCAAAIggAAEoIAAB2CAABEggAASoIAAISCAACVggAA0YIAANeCAADhggAA6YIAABOD AAAWgwAAT4MAAFODAADngwAA64MAAA+EAAAahAAAbIQAAHOEAACvhAAAtYQAAPeEAAAChQAA PoUAAEWFAACGhQAAjIUAAM2FAADShQAAFYYAABiGAABVhgAAYIYAALOGAAC2hgAA/IYAAP+G AABAhwAAS4cAAIiHAACLhwAAz4cAANOHAABciAAAYYgAAKWIAACpiAAAMIkAADeJAAB3iQAA fIkAALyJAADAiQAABIoAAAmKAABHigAAT4oAAOKKAADnigAAKosAACyLAABfiwAAcIsAAEuM AABSjAAA2IwAAOOMAAA3jQAAPo0AAKiNAACzjQAA8I0AAPSNAAA3jgAAPo4AAEWOAABLjgAA VY4AAFuOAACBjgAAhI4AAK+OAAC6jgAA4o4AAO+OAAAQjwAAFo8AAEePAABOjwAA/48AAAiQ AABhkAAAZJAAAM2QAADZkAAAKJEAACyRAAAHkgAAEZIAAE2SAABWkgAA8ZIAACCTAAAmkwAA N5MAAL+TAADFkwAAz5MAANWTAAD6kwAA/5MAABiUAAAflAAAR5QAAE6UAABqlAAAeJQAAJiU AAColAAAzZQAAN6UAAASlQAAHZUAAEmVAABPlQAAWZUAAGGVAACglQAAqJUAAOiVAADrlQAA PpYAAEmWAACclgAAnpYAAOCWAADolgAAI5cAACyXAACqlwAAr5cAACOYAAAtmAAAZ5gAAGyY AACumAAAtJgAAPGYAAD3mAAANpkAAD2ZAAB+mQAAh5kAAMSZAADHmQAABJoAABWaAACdmgAA o5oAAK2aAAC1mgAA8poAAPqaAAA4mwAAO5sAAIGbAACFmwAAyZsAAMybAAASnAAAFZwAAFuc AABenAAApJwAAKecAAAwnQAANp0AAGadAABsnQAAdp0AAH6dAAC2nQAAwp0AABeeAAAingAA W54AAGGeAAClngAArp4AAAefAAAJnwAAT58AAFWfAADZnwAA358AABygAAAooAAATqAAAFOg AABgoAAAZqAAAKigAACwoAAA7aAAAPOgAAAkoQAAKqEAADShAAA6oQAAa6EAAG6hAACgoQAA o6EAANWhAADYoQAAAqIAABOiAABCowAARqMAALCjAAC5owAA66MAAPOjAAD3owAABaQAAHOk AACApAAAt6QAALykAAD+pAAAAaUAADqlAABHpQAAgqUAAImlAADDpQAAzqUAAAGmAAAMpgAA RqYAAEqmAACLpgAAj6YAAMymAADUpgAAWacAAGCnAAChpwAAo6cAAA+oAAAcqAAApqgAAK6o AADuqAAAIqkAADupAABMqQAA1KkAAOCpAADxqgAA/6oAAMerAADpqwAAQ6wAAHesAADMrAAA 16wAAPmsAAAVrQAA664AAPyuAACAsAAAkbAAAMuwAADQsAAA2bAAADq2AAAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcABwAzAAcAAAAAAMMeAADHHgAAyB4AAMgeAABQIAAAUSAAAGkyAABpMgAA nDIAAJwyAADDMgAAxTIAAMYyAADGMgAA8TIAAPEyAAACMwAAAjMAADczAAA3MwAAYjMAAGIz AABjMwAAYzMAABpOAAAbTgAAME4AAFVOAAB1WgAAdloAAPRtAAD1bQAAR28AAEhvAABTbwAA U28AAFhvAABZbwAAXW8AAF1vAAD9eAAAVXkAAPt8AAD8fAAAgX0AAIJ9AAAahAAAGoQAAGGE AABohAAAI4gAACSIAAABjAAADowAAA+MAAAPjAAAyrAAAMuwAADMsAAA2rAAANuwAAA3tgAA OrYAAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAcAAwAEAAcABAAHAAEAXWEDT8hiUNP/D/8P/w//D/8P/w//D/8P/w8QAAMA AAAXAAAAAAAAAAAAAAAAAAAAAAAAABMQAAAPhNACEYSY/l6E0AJghJj+T0oBAFBKBABRSgEA XkoAAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY /k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA FRAAAA+EcAgRhJj+XoRwCGCEmP5PSgcAUUoHAG8oAIdoAAAAAIhIAAABAKfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI AAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgMA UUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUQAAAP hOAQEYSY/l6E4BBghJj+T0oHAFFKBwBvKACHaAAAAACISAAAAQCn8AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAABUQAAAPhLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC3 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABkQAAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBe SgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVEAAAD4RQGRGE mP5ehFAZYISY/k9KBwBRSgcAbygAh2gAAAAAiEgAAAEAp/ABAAAAXWEDTwAAAAAAAAAAAAAA AP///////wEAAAAAAP//AQAAABIAPmNAoAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQF AAkEGAAAAAQAAAAIAAAA5QAAAAAAAAARAAAAFVQLAMgWEABAExYAVioZAL5xJAAiPCgAKiox ANw6NwDMQzwAIUQ8AN8hbwCja3IAQSCBAGNQiwDRXJcATGenAEdgqAA9CasAhQ3QABA90AB+ PNoA9RLbAPoY5wDHdf4AAAAAAMuwAADNsAAAAAAAAAEAAAD/QAGAAQAOjAAADowAAADg6gEB AAEADowAAAAAAAAOjAAAAAAAAAIQAAAAAAAAADm2AAB4AAAQAEAAAP//AgAAAAcAVQBuAGsA bgBvAHcAbgAUAEMAZQBuAHQAdQByAHkATABpAG4AawAgAEUAbQBwAGwAbwB5AGUAZQD//wIA CAAAAAAAAAAAAAAAAAAAAAAAAAABAP//AgAAAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAA AAAJAAAARx6QAQAAAgIGAwUEBQIDBP8qAOBBeADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAA AAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMy6QAQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAA AAD/AQAAAAAAAEEAcgBpAGEAbAAAAD89kAEAAAIHAwkCAgUCBAT/KgDgQ3gAwAkAAAAAAAAA /wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA3LpABAAACDwUCAgIEAwIE/wIA4f+s AEAJAAAAAAAAAJ8BAAAAAAAAQwBhAGwAaQBiAHIAaQAAADk9kAEAAAILBgkCAgQDAgT/AgDh //wAQAkAAAAAAAAAnwEAAAAAAABDAG8AbgBzAG8AbABhAHMAAAA1LpABAAACCwYEAwUEBAIE /y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA7DpABAgAFAAAAAAAAAAAA AAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAABBHpABAAACBAUD BQQGAwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgA AAAiAAQAcYiNGADw0AIAAGgBAAAAAAlaI0fCWiNHAAAAABEAqAAAAGMaAABolgAAFgBaAAAA BAADkEABAABjGgAAaJYAABYAWgAAAEABAAAAAAAA2QMA8BAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2gXwA7QAtACBgTIwAAAAAAAAAAAAAAAAAABxsAAA cbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIAAAAAAAAAAAAAM4MRAPAQAAgA/P0BAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACEhYAAAAAAnw/w8BCCRQAAAAAAAAvh4AAP///3////9/AAAAAP///3////9/////f75x JAAABAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAgA AAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAP//EgAAAAAAAAAAAAAAAAAAABQAQwBlAG4A dAB1AHIAeQBMAGkAbgBrACAARQBtAHAAbABvAHkAZQBlABQAQwBlAG4AdAB1AHIAeQBMAGkA bgBrACAARQBtAHAAbABvAHkAZQBlAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAYAAAABAAAA AAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAB4AQAA EAAAAAEAAACIAAAAAgAAAJAAAAADAAAAnAAAAAQAAACoAAAABQAAAMgAAAAHAAAA1AAAAAgA AADoAAAACQAAAAgBAAASAAAAFAEAAAoAAAA0AQAADAAAAEABAAANAAAATAEAAA4AAABYAQAA DwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAAAOQEAAAeAAAABAAAAAAAAAAeAAAABAAAAAAA AAAeAAAAGAAAAENlbnR1cnlMaW5rIEVtcGxveWVlAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAA Tm9ybWFsLmRvdG0AHgAAABgAAABDZW50dXJ5TGluayBFbXBsb3llZQAAAAAeAAAABAAAADE3 AAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAA8CV4FwAAAEAAAAAApg5z Mz3PAUAAAAAA9ASeSz3PAQMAAAAWAAAAAwAAAGMaAAADAAAAaJYAAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYB AgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA8AAAAAwAAAABAAAA aAAAAA8AAABwAAAABQAAAIQAAAAGAAAAjAAAABEAAACUAAAAFwAAAJwAAAALAAAApAAAABAA AACsAAAAEwAAALQAAAAWAAAAvAAAAA0AAADEAAAADAAAANEAAAACAAAA5AQAAB4AAAAMAAAA Q2VudHVyeUxpbmsAAwAAAEABAAADAAAAWgAAAAMAAABxsAAAAwAAAAAADAALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0 bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA EgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAA LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoA AAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAA SAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUA AABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAA YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAA AABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAA fgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsA AACMAAAAjQAAAI4AAAD+////kAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAP7///+YAAAA mQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAAAKYA AACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAA tAAAALUAAAC2AAAAtwAAALgAAAC5AAAA/v///7sAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEA AAD+////wwAAAMQAAADFAAAAxgAAAMcAAADIAAAAyQAAAP7////9/////f///80AAAD+//// /v////7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf// ////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACw5dCySz3PAc8AAACAAAAA AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAjwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACXAAAAvkQAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA0HAEAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAugAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADCAAAAABAAAAAAAAABAEMA bwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGJwAAAE1pY3Jvc29mdCBPZmZp Y2UgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1l bnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --------------010805090302010505010507-- From nobody Tue Mar 11 10:26:51 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850C11A0636 for ; Tue, 11 Mar 2014 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF0tKbjbT9hx for ; Tue, 11 Mar 2014 10:26:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id D85371A0584 for ; Tue, 11 Mar 2014 10:26:47 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 11 Mar 2014 17:26:43 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 11 Mar 2014 17:26:40 +0000 From: To: , Date: Tue, 11 Mar 2014 17:26:38 +0000 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt Thread-Index: Ac89TZuMCTiUFC35TpSIR89h2koFRAAAGScw Message-ID: References: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> <531F44A7.8010604@centurylink.com> In-Reply-To: <531F44A7.8010604@centurylink.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/XuI27koi1KNohemnphEN7MuLXXQ Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:26:50 -0000 Thanks for the comments Charles. Some of these were covered in the suggested updates during the IETF LMAP se= ssion, but see inline for answers.... >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook >Sent: 11 March 2014 17:15 >To: lmap@ietf.org >Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt > >I finally got around to reviewing the Information Model. Attached are my >comments. > >In summary: > >It appears that the Information Channel is being referenced with Pre- >configuration information rather than Configuration information. >Pre-configuration information cannot be provided via the Information Chann= el >because the MA has to register with the Controller before it can receive >Configuration information from the Controller. We're going to make the whole concept of channels a lot simpler. In the pre= -config the MA will need an initial channel to contact the Controller. We n= o longer bind this channel to specific types of data (config, instruction, = capabilities, logging etc.) or to a specific timing. Any channel will simpl= y become a secure communication channel to an end-point. Hopefully will make things a lot clearer (and also more flexible). >There is a reference that Measurement Tasks will be executed "in order" >which may imply "serially" to some. It would be more accurate to say exec= uted >per the Measurement Schedule. It does say that, and we did indeed mean serialised! We wanted the ability = to specify a non-overlapping list of things to do in a single schedule. If = you want to overlap then use multiple schedules. >At one time I thought I heard that one of the "Elements" may be split into= two >Elements. If that happens, the draft will need to be updated. >Given the recent discussion on Active vs Passive, maybe that is no longer = under >consideration. I think this was probably the one-off vs. repeated tasks. We agreed the inf= ormation model does not need to split these (other than by the use of diffe= rent timing objects). It is up to the protocol implementation into whether = one-off and repeated tests are updated separately (or indeed any breakdown = of the instruction). >Regarding Operational Update messages, consideration should be given to a >"Scheduling conflict" message. This may also need to be mentioned in Sect= ion >3.7 "Reporting Information". Yes, I discussed on the last slide that we need further discussion on the r= eporting of test collisions. >There were also a few editorial items. Will make sure we catch them in the forthcoming 01 edit. >Overall, it is looking good. Thanks! >Charles Trevor. >On 2/16/2014 8:20 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> 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-00.txt >> Pages : 21 >> Date : 2014-02-14 >> >> 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-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.ie= tf.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 >> > >-- > >Charles Cook >Principal Architect >Network >5325 Zuni Street; Suite 224 >Denver, CO 80221 >Tel: 303.992.8952 Fax: 925.281.0662 >charles.cook2@centurylink.com From nobody Tue Mar 11 10:36:06 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C401A0493 for ; Tue, 11 Mar 2014 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6] 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 s_qWcdjE-5a5 for ; Tue, 11 Mar 2014 10:36:03 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5E1A078F for ; Tue, 11 Mar 2014 10:35:59 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2BHZoR4001490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 11:35:50 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1DCD71E0080; Tue, 11 Mar 2014 12:35:45 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E8D7C1E00AE; Tue, 11 Mar 2014 12:35:44 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHZixM025829; Tue, 11 Mar 2014 12:35:44 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHZhRw025811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 12:35:44 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex501.ctl.intranet ([151.117.206.27]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 12:35:43 -0500 From: "Bugenhagen, Michael K" To: "Bugenhagen, Michael K" , "'Romascanu, Dan (Dan)'" , "'MORTON, ALFRED C (AL)'" , "'Brian Trammell'" Thread-Topic: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2Ay6PnPFJo/0eeoDd4KhTzipraqfuAgAGR5YCAAAF+gIAAKhkAgAADNwCAAAGUgIAABW8AgAACdgD//7DUsIAAB2ew Date: Tue, 11 Mar 2014 17:35:42 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/a7pFWdKd4de_GFKb513koUYTPXk Cc: 'Matt Mathis' , "'lmap@ietf.org'" Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 17:36:05 -0000 Waiting for someone to call me out on 3 levels vs. 2 level...=20 i.e....=20 LMAP / WT-304 Specific OAM level MA (Y.1731, OWAMP, TWAMP) Protocol level One could group LMAP/WT-304 along with specific OAM level protocols... or w= e could split them.. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Tuesday, March 11, 2014 12:14 PM To: 'Romascanu, Dan (Dan)'; 'MORTON, ALFRED C (AL)'; 'Brian Trammell' Cc: 'Matt Mathis'; 'lmap@ietf.org' Subject: Re: [lmap] One example of a "passive measurement peer" Here's what I meant by contextualization of the "verb" passive... Passive means "not to react" to something..(if we're sticking to Webster's = definition) So contextually a=20 1) Passive test - means the test of the subject would not react - so the se= rvice resources, and service flow are NOT impacted 2) Passive peer (should not exist.. because it wouldn't react ? ... right=20 I think the real issue here is that we're talking about the different layer= reactors (server entities)=20 That are in a protocol like Ping, OWAMP, TWAMP, ...=20 Vs. A LMAP probe "server function"=20 You could have a test that is passive to a LMAP probe level, but Active at = a lower protocol level. This is why we introduced a hierarchy like this on the BBF side. Suggestion to un wrinkle this-- 1) Describe the probe agent layer terms Protocol based Measurement agent (distributed control / self contained con= trol) Vs. LMAP based MA -=20 Then Active / Passive starts making sense again. Regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, March 11, 2014 11:51 AM To: MORTON, ALFRED C (AL); Brian Trammell Cc: Matt Mathis; lmap@ietf.org Subject: Re: [lmap] One example of a "passive measurement peer" OK - so maybe it is there (in IPPM) where 'active' and 'passive' need to be= defined. The criteria in my mind was whether traffic was generated beyond = the payload and control traffic that belongs to the protocols on the networ= k with the explicit purpose of executing a measurement procedure. I need ho= wever to read more on the IPPM context.=20 Regards,=20 Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, March 11, 2014 6:42 PM > To: Romascanu, Dan (Dan); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR=20 > metrics need to appear in the Registry (which is currently split into=20 > passive and active sub-registries), so that the LMAP Control and=20 > Collection protocols can refer to them. >=20 > And this is an area where IPPM'ers seek LMAP'er comments. > Al >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2014 12:23 PM > > To: MORTON, ALFRED C (AL); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Al, > > > > The behavior that you describe has nothing to do with LMAP. It=20 > > belongs to the RTP protocol. No traffic is generated as a result of=20 > > the fact that the remote endpoint is a peer. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, March 11, 2014 6:17 PM > > > To: Romascanu, Dan (Dan); Brian Trammell > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > Hi Dan, > > > > > > I don't see the RTP end-point as purely active of course, but not=20 > > > purely passive either, because of the measure of knowledge of its=20 > > > streams and control over them (e.g., in response to RTCP reports,=20 > > > the stream characteristics might be adjusted). > > > > > > I think RTP end-points fit within the taxonomy of hybrid (aspects=20 > > > which > > are > > > both active & passive) techniques, like the IPv6 PDM, packet=20 > > > coloring, > > and > > > others. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Tuesday, March 11, 2014 12:06 PM > > > > To: MORTON, ALFRED C (AL); Brian Trammell > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > > > Hi Al, > > > > > > > > You tried to explain by you did not convince me :-) > > > > > > > > I do not see the remote RTP end-point as 'active'. There is=20 > > > > nothing it does differently (no 'activity') as the result of=20 > > > > being a measurement peer. > > > > > > > > However, I agree that removing 'active' from this document=20 > > > > solves the dispute. If there is no 'active' there is no need to def= ine 'passive'. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON,=20 > > > > > ALFRED C (AL) > > > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > +1, I briefly tried to explain this to Dan in the back of the=20 > > > > > +LMAP > > > > > meeting room (while the meeting was still in-progress, I think). > > > > > > > > > > For me, it's a key distinction that the RTCP-reported=20 > > > > > end-point measurements have a priori knowledge of the stream=20 > > > > > in RTP (like active), while true passive measurements (at mid poi= nts) do not. > > > > > > > > > > Al > > > > > > > > > > > -----Original Message----- > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian=20 > > > > > > Trammell > > > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > > > To: Dan Romascanu > > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > hi Dan, > > > > > > > > > > > > Hm. I don't really consider this passive measurement -- we=20 > > > > > > discussed this a bit in the ippm registry design team, but=20 > > > > > > I'm pretty sure there's a difference between (1) metrics=20 > > > > > > derived from the operation of a protocol at one of the=20 > > > > > > endpoints participating in it and (2) metrics derived from=20 > > > > > > the passive observation of packets emitted by those=20 > > > > > > protocols. I've always thought of passive measurement as the=20 > > > > > > latter, and (1) as something like "endpoint measurement",=20 > > > > > > since metrics in (1) can also be derived from internal state=20 > > > > > > at each endpoint not synchronized over the protocol > > or > > > otherwise hard to derive. > > > > > > > > > > > > One could say that a midpath observation point (i.e. any=20 > > > > > > observation point other than an endpoint) has as many=20 > > > > > > "passive peers" as there are observable senders and=20 > > > > > > recipients, while an "endpoint measurement > > > > > agent" > > > > > > would have a single "endpoint peer". > > > > > > > > > > > > (This becomes a much more interesting distinction as soon as=20 > > > > > > you consider encrypting absolutely everything you can, of=20 > > > > > > course. At that point everything you're reduced to endpoint=20 > > > > > > measurement for everything other than the "envelope" and/or=20 > > > > > > things you derive through behavioral traffic analysis. But=20 > > > > > > that's a separate discussion, I think.) > > > > > > > > > > > > In any case, I stand by my statement that I'd like to see=20 > > > > > > peers defined _only_ as much as is absolutely necessary to=20 > > > > > > make sense of the resulting control and reporting protocols. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan)=20 > > > > > > > > > > > wrote: > > > > > > > > > > > > > My other example of a 'passive management peer' is an RTP=20 > > > > > > > peer which > > > > > > receives RTCP messages about the state of the other side of=20 > > > > > > the connection and the parameters of the received traffic at=20 > > > > > > the other end. All these are part of RTP/RTCP, there is no=20 > > > > > > interaction between the controller and the MP, so I believe=20 > > > > > > it can be considered passive > > > > in LMAP > > > > > terms. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of=20 > > > > > > > Matt Mathis > > > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > > > To: lmap@ietf.org > > > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > > > From the Internet Archive: > > > > > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > > > didc.lbl.gov/SC > > > > > > > NM/ > > > > > > > > > > > > > > Thanks, > > > > > > > --MM-- > > > > > > > The best way to predict the future is to create it. -=20 > > > > > > > Alan Kay > > > > > > > > > > > > > > Privacy matters! We know from recent events that people=20 > > > > > > > are using our > > > > > > services to speak in defiance of unjust governments. We treat > > > > privacy > > > > > > and security as matters of life and death, because for some=20 > > > > > > users, they are. > > > > > > > _______________________________________________ > > > > > > > lmap mailing list > > > > > > > lmap@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > _______________________________________________ > > > > > > lmap mailing list > > > > > > lmap@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 10:53:44 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24231A0736 for ; Tue, 11 Mar 2014 10:53:42 -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 kOGoO-lCcHZ3 for ; Tue, 11 Mar 2014 10:53:40 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 747E51A0747 for ; Tue, 11 Mar 2014 10:53:40 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2BHrVpL019373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 11:53:31 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id DB1E31E006B; Tue, 11 Mar 2014 11:53:25 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B54F91E005F; Tue, 11 Mar 2014 11:53:25 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHrPjU026088; Tue, 11 Mar 2014 12:53:25 -0500 (CDT) Received: from [10.188.208.192] (x1069818.dhcp.intranet [10.188.208.192]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BHrN0u026038; Tue, 11 Mar 2014 12:53:23 -0500 (CDT) Message-ID: <531F4D92.3090806@centurylink.com> Date: Tue, 11 Mar 2014 11:53:22 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: trevor.burbridge@bt.com References: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> <531F44A7.8010604@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/h7TXPX-oz-4A4dnbDpDKSA7G-lQ Cc: lmap@ietf.org Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: charles.cook2@centurylink.com List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:53:43 -0000 Trevor, Thanks for the clarifications. One more question regarding the serialization of the Measurement Tasks. When you say "in order", do you mean in order as they were sent to the MA, or do you mean in order as they are scheduled? I assume it is that later, but without that clarification in the draft some may think the former. For example, the Controller could send Measurement Tasks A, B, and C in that order. But when you look at the Measurement Schedule it may say do B first, followed by C, followed by A. Now we have an ambiguity. That is why I think what we really want to say is that the Measurement Tasks will be executed "in order based on the Measurement Schedule". Let me know if I am missing something. Charles On 3/11/2014 11:26 AM, trevor.burbridge@bt.com wrote: > Thanks for the comments Charles. > > Some of these were covered in the suggested updates during the IETF LMAP session, but see inline for answers.... > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook >> Sent: 11 March 2014 17:15 >> To: lmap@ietf.org >> Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt >> >> I finally got around to reviewing the Information Model. Attached are my >> comments. >> >> In summary: >> >> It appears that the Information Channel is being referenced with Pre- >> configuration information rather than Configuration information. >> Pre-configuration information cannot be provided via the Information Channel >> because the MA has to register with the Controller before it can receive >> Configuration information from the Controller. > We're going to make the whole concept of channels a lot simpler. In the pre-config the MA will need an initial channel to contact the Controller. We no longer bind this channel to specific types of data (config, instruction, capabilities, logging etc.) or to a specific timing. Any channel will simply become a secure communication channel to an end-point. > > Hopefully will make things a lot clearer (and also more flexible). > >> There is a reference that Measurement Tasks will be executed "in order" >> which may imply "serially" to some. It would be more accurate to say executed >> per the Measurement Schedule. > It does say that, and we did indeed mean serialised! We wanted the ability to specify a non-overlapping list of things to do in a single schedule. If you want to overlap then use multiple schedules. > >> At one time I thought I heard that one of the "Elements" may be split into two >> Elements. If that happens, the draft will need to be updated. >> Given the recent discussion on Active vs Passive, maybe that is no longer under >> consideration. > I think this was probably the one-off vs. repeated tasks. We agreed the information model does not need to split these (other than by the use of different timing objects). It is up to the protocol implementation into whether one-off and repeated tests are updated separately (or indeed any breakdown of the instruction). > >> Regarding Operational Update messages, consideration should be given to a >> "Scheduling conflict" message. This may also need to be mentioned in Section >> 3.7 "Reporting Information". > Yes, I discussed on the last slide that we need further discussion on the reporting of test collisions. > >> There were also a few editorial items. > Will make sure we catch them in the forthcoming 01 edit. > >> Overall, it is looking good. > Thanks! > >> Charles > Trevor. > >> On 2/16/2014 8:20 AM, internet-drafts@ietf.org wrote: >>> 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-00.txt >>> Pages : 21 >>> Date : 2014-02-14 >>> >>> 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-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/ >>> >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>> >> -- >> >> Charles Cook >> Principal Architect >> Network >> 5325 Zuni Street; Suite 224 >> Denver, CO 80221 >> Tel: 303.992.8952 Fax: 925.281.0662 >> charles.cook2@centurylink.com > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com From nobody Tue Mar 11 11:11:38 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90471A047E for ; Tue, 11 Mar 2014 11:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6] 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 ddY4myAW9SZm for ; Tue, 11 Mar 2014 11:11:28 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D7BF81A0747 for ; Tue, 11 Mar 2014 11:11:25 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2BIBGZ4008892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 12:11:16 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5F3011E0049; Tue, 11 Mar 2014 13:11:11 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 3EA8E1E007D; Tue, 11 Mar 2014 13:11:11 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BIBACW024655; Tue, 11 Mar 2014 13:11:10 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s2BIBAWu024652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 13:11:10 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 13:11:09 -0500 From: "Bugenhagen, Michael K" To: "Bugenhagen, Michael K" , "'Romascanu, Dan (Dan)'" , "'MORTON, ALFRED C (AL)'" , "'Brian Trammell'" Thread-Topic: clarrification -- RE: [lmap] One example of a "passive measurement peer" Thread-Index: AQHPOe2Ay6PnPFJo/0eeoDd4KhTzipraqfuAgAGR5YCAAAF+gIAAKhkAgAADNwCAAAGUgIAABW8AgAACdgD//7DUsIAAB2ewgAAHBbA= Date: Tue, 11 Mar 2014 18:11:08 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Zk-ihiXJeYL_p1FvcH04Fe6eY-0 Cc: 'Matt Mathis' , "'lmap@ietf.org'" Subject: [lmap] clarrification -- RE: One example of a "passive measurement peer" 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, 11 Mar 2014 18:11:37 -0000 Suggestion / proposal for responder types / layers In terms of Agent / Responder types... I think we'd have to decompose the = agent / responders to the following levels. This way it's very clear what's being done (and more important at which lay= er the resources are being hit) Which layer does Test Admin restrictions (TWAMP has it's own) Which layer does Node level Resource checks (over all CAC functions) .... i.e. - All tests hit some level (tracking counters is passive to traffic bu= t consume cpu & memory) so they hit the counter level resource. Ping Tests hit the IP protocol stack resource. The "passive test peer" - actually said it doesn't impact the "peer level" = service probe layer, but could impact the OAM / Application layers Again - I think an OAM probe could be either Service layer or application s= pecific (MEF does that approach with Multi-class of service OAM). So Probe level / Layer wise I'm suggesting it would look like this (define = the parts so we can define the relationship between the parts). =20 Service Probe Layer ------- General purpose | |=09 Test anything Agent | | ------- OAM and Application=20 Specific responder layer ------- Y.1731 | |=09 O/T WAMP | | RTP/RTCP / Timing ------- =20 IP protocol responder Layer ------- PING / ICMP | |=09 | | ------- Counter and Atomic level ------- Resources / Agents | | | | ------- -----Original Message----- From: Bugenhagen, Michael K=20 Sent: Tuesday, March 11, 2014 12:36 PM To: Bugenhagen, Michael K; 'Romascanu, Dan (Dan)'; 'MORTON, ALFRED C (AL)';= 'Brian Trammell' Cc: 'Matt Mathis'; 'lmap@ietf.org' Subject: RE: [lmap] One example of a "passive measurement peer" Waiting for someone to call me out on 3 levels vs. 2 level...=20 i.e....=20 LMAP / WT-304 Specific OAM level MA (Y.1731, OWAMP, TWAMP) Protocol level One could group LMAP/WT-304 along with specific OAM level protocols... or w= e could split them.. -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bugenhagen, Michael = K Sent: Tuesday, March 11, 2014 12:14 PM To: 'Romascanu, Dan (Dan)'; 'MORTON, ALFRED C (AL)'; 'Brian Trammell' Cc: 'Matt Mathis'; 'lmap@ietf.org' Subject: Re: [lmap] One example of a "passive measurement peer" Here's what I meant by contextualization of the "verb" passive... Passive means "not to react" to something..(if we're sticking to Webster's = definition) So contextually a=20 1) Passive test - means the test of the subject would not react - so the se= rvice resources, and service flow are NOT impacted 2) Passive peer (should not exist.. because it wouldn't react ? ... right=20 I think the real issue here is that we're talking about the different layer= reactors (server entities)=20 That are in a protocol like Ping, OWAMP, TWAMP, ...=20 Vs. A LMAP probe "server function"=20 You could have a test that is passive to a LMAP probe level, but Active at = a lower protocol level. This is why we introduced a hierarchy like this on the BBF side. Suggestion to un wrinkle this-- 1) Describe the probe agent layer terms Protocol based Measurement agent (distributed control / self contained con= trol) Vs. LMAP based MA -=20 Then Active / Passive starts making sense again. Regards, Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, March 11, 2014 11:51 AM To: MORTON, ALFRED C (AL); Brian Trammell Cc: Matt Mathis; lmap@ietf.org Subject: Re: [lmap] One example of a "passive measurement peer" OK - so maybe it is there (in IPPM) where 'active' and 'passive' need to be= defined. The criteria in my mind was whether traffic was generated beyond = the payload and control traffic that belongs to the protocols on the networ= k with the explicit purpose of executing a measurement procedure. I need ho= wever to read more on the IPPM context.=20 Regards,=20 Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Tuesday, March 11, 2014 6:42 PM > To: Romascanu, Dan (Dan); Brian Trammell > Cc: Matt Mathis; lmap@ietf.org > Subject: RE: [lmap] One example of a "passive measurement peer" >=20 > Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR=20 > metrics need to appear in the Registry (which is currently split into=20 > passive and active sub-registries), so that the LMAP Control and=20 > Collection protocols can refer to them. >=20 > And this is an area where IPPM'ers seek LMAP'er comments. > Al >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, March 11, 2014 12:23 PM > > To: MORTON, ALFRED C (AL); Brian Trammell > > Cc: Matt Mathis; lmap@ietf.org > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > Hi Al, > > > > The behavior that you describe has nothing to do with LMAP. It=20 > > belongs to the RTP protocol. No traffic is generated as a result of=20 > > the fact that the remote endpoint is a peer. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Tuesday, March 11, 2014 6:17 PM > > > To: Romascanu, Dan (Dan); Brian Trammell > > > Cc: Matt Mathis; lmap@ietf.org > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > Hi Dan, > > > > > > I don't see the RTP end-point as purely active of course, but not=20 > > > purely passive either, because of the measure of knowledge of its=20 > > > streams and control over them (e.g., in response to RTCP reports,=20 > > > the stream characteristics might be adjusted). > > > > > > I think RTP end-points fit within the taxonomy of hybrid (aspects=20 > > > which > > are > > > both active & passive) techniques, like the IPv6 PDM, packet=20 > > > coloring, > > and > > > others. > > > > > > Al > > > > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Tuesday, March 11, 2014 12:06 PM > > > > To: MORTON, ALFRED C (AL); Brian Trammell > > > > Cc: Matt Mathis; lmap@ietf.org > > > > Subject: RE: [lmap] One example of a "passive measurement peer" > > > > > > > > Hi Al, > > > > > > > > You tried to explain by you did not convince me :-) > > > > > > > > I do not see the remote RTP end-point as 'active'. There is=20 > > > > nothing it does differently (no 'activity') as the result of=20 > > > > being a measurement peer. > > > > > > > > However, I agree that removing 'active' from this document=20 > > > > solves the dispute. If there is no 'active' there is no need to def= ine 'passive'. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON,=20 > > > > > ALFRED C (AL) > > > > > Sent: Tuesday, March 11, 2014 3:35 PM > > > > > To: Brian Trammell; Romascanu, Dan (Dan) > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > +1, I briefly tried to explain this to Dan in the back of the=20 > > > > > +LMAP > > > > > meeting room (while the meeting was still in-progress, I think). > > > > > > > > > > For me, it's a key distinction that the RTCP-reported=20 > > > > > end-point measurements have a priori knowledge of the stream=20 > > > > > in RTP (like active), while true passive measurements (at mid poi= nts) do not. > > > > > > > > > > Al > > > > > > > > > > > -----Original Message----- > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian=20 > > > > > > Trammell > > > > > > Sent: Tuesday, March 11, 2014 9:30 AM > > > > > > To: Dan Romascanu > > > > > > Cc: Matt Mathis; lmap@ietf.org > > > > > > Subject: Re: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > hi Dan, > > > > > > > > > > > > Hm. I don't really consider this passive measurement -- we=20 > > > > > > discussed this a bit in the ippm registry design team, but=20 > > > > > > I'm pretty sure there's a difference between (1) metrics=20 > > > > > > derived from the operation of a protocol at one of the=20 > > > > > > endpoints participating in it and (2) metrics derived from=20 > > > > > > the passive observation of packets emitted by those=20 > > > > > > protocols. I've always thought of passive measurement as the=20 > > > > > > latter, and (1) as something like "endpoint measurement",=20 > > > > > > since metrics in (1) can also be derived from internal state=20 > > > > > > at each endpoint not synchronized over the protocol > > or > > > otherwise hard to derive. > > > > > > > > > > > > One could say that a midpath observation point (i.e. any=20 > > > > > > observation point other than an endpoint) has as many=20 > > > > > > "passive peers" as there are observable senders and=20 > > > > > > recipients, while an "endpoint measurement > > > > > agent" > > > > > > would have a single "endpoint peer". > > > > > > > > > > > > (This becomes a much more interesting distinction as soon as=20 > > > > > > you consider encrypting absolutely everything you can, of=20 > > > > > > course. At that point everything you're reduced to endpoint=20 > > > > > > measurement for everything other than the "envelope" and/or=20 > > > > > > things you derive through behavioral traffic analysis. But=20 > > > > > > that's a separate discussion, I think.) > > > > > > > > > > > > In any case, I stand by my statement that I'd like to see=20 > > > > > > peers defined _only_ as much as is absolutely necessary to=20 > > > > > > make sense of the resulting control and reporting protocols. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan)=20 > > > > > > > > > > > wrote: > > > > > > > > > > > > > My other example of a 'passive management peer' is an RTP=20 > > > > > > > peer which > > > > > > receives RTCP messages about the state of the other side of=20 > > > > > > the connection and the parameters of the received traffic at=20 > > > > > > the other end. All these are part of RTP/RTCP, there is no=20 > > > > > > interaction between the controller and the MP, so I believe=20 > > > > > > it can be considered passive > > > > in LMAP > > > > > terms. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of=20 > > > > > > > Matt Mathis > > > > > > > Sent: Friday, March 07, 2014 12:11 PM > > > > > > > To: lmap@ietf.org > > > > > > > Subject: [lmap] One example of a "passive measurement peer" > > > > > > > > > > > > > > From the Internet Archive: > > > > > > > > > > > > > > http://web.archive.org/web/20071005130953/http://www- > > > > > didc.lbl.gov/SC > > > > > > > NM/ > > > > > > > > > > > > > > Thanks, > > > > > > > --MM-- > > > > > > > The best way to predict the future is to create it. -=20 > > > > > > > Alan Kay > > > > > > > > > > > > > > Privacy matters! We know from recent events that people=20 > > > > > > > are using our > > > > > > services to speak in defiance of unjust governments. We treat > > > > privacy > > > > > > and security as matters of life and death, because for some=20 > > > > > > users, they are. > > > > > > > _______________________________________________ > > > > > > > lmap mailing list > > > > > > > lmap@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > > > _______________________________________________ > > > > > > lmap mailing list > > > > > > lmap@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/lmap > > > > > > > > > > _______________________________________________ > > > > > lmap mailing list > > > > > lmap@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Mar 11 13:39:10 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACA51A072C for ; Tue, 11 Mar 2014 13:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P20aIPVs_je2 for ; Tue, 11 Mar 2014 13:39:06 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8F1A0643 for ; Tue, 11 Mar 2014 13:39:05 -0700 (PDT) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id E84D11A1081; Tue, 11 Mar 2014 21:38:14 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D7E348F1-5BBD-4D40-BA5D-BC175837E17A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Brian Trammell In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> Date: Tue, 11 Mar 2014 21:38:11 +0100 Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA2E44A926@AZ-FFEXMB04.global.avaya.com> <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> To: Dan Romascanu X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2k2dLaD0Z8DBpzvm4ZNNY_Jn7Xw Cc: "lmap@ietf.org" , Al Morton , Matt Mathis Subject: Re: [lmap] One example of a "passive measurement peer" 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, 11 Mar 2014 20:39:09 -0000 --Apple-Mail=_D7E348F1-5BBD-4D40-BA5D-BC175837E17A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Mar 2014, at 17:51, Romascanu, Dan (Dan) = wrote: > OK - so maybe it is there (in IPPM) where 'active' and 'passive' need = to be defined. Indeed, we'll refine this within IPPM as part of the registry effort, = the three core documents of which will be adopted as working groups = drafts shortly. > The criteria in my mind was whether traffic was generated beyond the = payload and control traffic that belongs to the protocols on the network = with the explicit purpose of executing a measurement procedure. I need = however to read more on the IPPM context.=20 There's no hard definition yet. I recall during the design team = discussions this being a point (passive vs "endpoint") being a point = which will require further refinement. Regards, Brian >> -----Original Message----- >> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >> Sent: Tuesday, March 11, 2014 6:42 PM >> To: Romascanu, Dan (Dan); Brian Trammell >> Cc: Matt Mathis; lmap@ietf.org >> Subject: RE: [lmap] One example of a "passive measurement peer" >>=20 >> Dan, perhaps the connection to LMAP is obscure, but the RTCP-XR = metrics >> need to appear in the Registry (which is currently split into passive = and active >> sub-registries), so that the LMAP Control and Collection protocols = can refer >> to them. >>=20 >> And this is an area where IPPM'ers seek LMAP'er comments. >> Al >>=20 >>> -----Original Message----- >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>> Sent: Tuesday, March 11, 2014 12:23 PM >>> To: MORTON, ALFRED C (AL); Brian Trammell >>> Cc: Matt Mathis; lmap@ietf.org >>> Subject: RE: [lmap] One example of a "passive measurement peer" >>>=20 >>> Hi Al, >>>=20 >>> The behavior that you describe has nothing to do with LMAP. It = belongs >>> to the RTP protocol. No traffic is generated as a result of the fact >>> that the remote endpoint is a peer. >>>=20 >>> Regards, >>>=20 >>> Dan >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>>> Sent: Tuesday, March 11, 2014 6:17 PM >>>> To: Romascanu, Dan (Dan); Brian Trammell >>>> Cc: Matt Mathis; lmap@ietf.org >>>> Subject: RE: [lmap] One example of a "passive measurement peer" >>>>=20 >>>> Hi Dan, >>>>=20 >>>> I don't see the RTP end-point as purely active of course, but not >>>> purely passive either, because of the measure of knowledge of its >>>> streams and control over them (e.g., in response to RTCP reports, >>>> the stream characteristics might be adjusted). >>>>=20 >>>> I think RTP end-points fit within the taxonomy of hybrid (aspects >>>> which >>> are >>>> both active & passive) techniques, like the IPv6 PDM, packet >>>> coloring, >>> and >>>> others. >>>>=20 >>>> Al >>>>=20 >>>>> -----Original Message----- >>>>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>>>> Sent: Tuesday, March 11, 2014 12:06 PM >>>>> To: MORTON, ALFRED C (AL); Brian Trammell >>>>> Cc: Matt Mathis; lmap@ietf.org >>>>> Subject: RE: [lmap] One example of a "passive measurement peer" >>>>>=20 >>>>> Hi Al, >>>>>=20 >>>>> You tried to explain by you did not convince me :-) >>>>>=20 >>>>> I do not see the remote RTP end-point as 'active'. There is >>>>> nothing it does differently (no 'activity') as the result of being >>>>> a measurement peer. >>>>>=20 >>>>> However, I agree that removing 'active' from this document solves >>>>> the dispute. If there is no 'active' there is no need to define = 'passive'. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Dan >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, >>>>>> ALFRED C (AL) >>>>>> Sent: Tuesday, March 11, 2014 3:35 PM >>>>>> To: Brian Trammell; Romascanu, Dan (Dan) >>>>>> Cc: Matt Mathis; lmap@ietf.org >>>>>> Subject: Re: [lmap] One example of a "passive measurement peer" >>>>>>=20 >>>>>> +1, I briefly tried to explain this to Dan in the back of the >>>>>> +LMAP >>>>>> meeting room (while the meeting was still in-progress, I think). >>>>>>=20 >>>>>> For me, it's a key distinction that the RTCP-reported end-point >>>>>> measurements have a priori knowledge of the stream in RTP (like >>>>>> active), while true passive measurements (at mid points) do not. >>>>>>=20 >>>>>> Al >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian >>>>>>> Trammell >>>>>>> Sent: Tuesday, March 11, 2014 9:30 AM >>>>>>> To: Dan Romascanu >>>>>>> Cc: Matt Mathis; lmap@ietf.org >>>>>>> Subject: Re: [lmap] One example of a "passive measurement peer" >>>>>>>=20 >>>>>>> hi Dan, >>>>>>>=20 >>>>>>> Hm. I don't really consider this passive measurement -- we >>>>>>> discussed this a bit in the ippm registry design team, but I'm >>>>>>> pretty sure there's a difference between (1) metrics derived >>>>>>> from the operation of a protocol at one of the endpoints >>>>>>> participating in it and (2) metrics derived from the passive >>>>>>> observation of packets emitted by those protocols. I've always >>>>>>> thought of passive measurement as the latter, and (1) as >>>>>>> something like "endpoint measurement", since metrics in (1) >>>>>>> can also be derived from internal state at each endpoint not >>>>>>> synchronized over the protocol >>> or >>>> otherwise hard to derive. >>>>>>>=20 >>>>>>> One could say that a midpath observation point (i.e. any >>>>>>> observation point other than an endpoint) has as many "passive >>>>>>> peers" as there are observable senders and recipients, while >>>>>>> an "endpoint measurement >>>>>> agent" >>>>>>> would have a single "endpoint peer". >>>>>>>=20 >>>>>>> (This becomes a much more interesting distinction as soon as >>>>>>> you consider encrypting absolutely everything you can, of >>>>>>> course. At that point everything you're reduced to endpoint >>>>>>> measurement for everything other than the "envelope" and/or >>>>>>> things you derive through behavioral traffic analysis. But >>>>>>> that's a separate discussion, I think.) >>>>>>>=20 >>>>>>> In any case, I stand by my statement that I'd like to see >>>>>>> peers defined _only_ as much as is absolutely necessary to >>>>>>> make sense of the resulting control and reporting protocols. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>>=20 >>>>>>> On 10 Mar 2014, at 14:31, Romascanu, Dan (Dan) >>>>>>> >>>>>> wrote: >>>>>>>=20 >>>>>>>> My other example of a 'passive management peer' is an RTP >>>>>>>> peer which >>>>>>> receives RTCP messages about the state of the other side of >>>>>>> the connection and the parameters of the received traffic at >>>>>>> the other end. All these are part of RTP/RTCP, there is no >>>>>>> interaction between the controller and the MP, so I believe it >>>>>>> can be considered passive >>>>> in LMAP >>>>>> terms. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Dan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Matt >>>>>>>> Mathis >>>>>>>> Sent: Friday, March 07, 2014 12:11 PM >>>>>>>> To: lmap@ietf.org >>>>>>>> Subject: [lmap] One example of a "passive measurement peer" >>>>>>>>=20 >>>>>>>> =46rom the Internet Archive: >>>>>>>>=20 >>>>>>>> http://web.archive.org/web/20071005130953/http://www- >>>>>> didc.lbl.gov/SC >>>>>>>> NM/ >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> --MM-- >>>>>>>> The best way to predict the future is to create it. - Alan >>>>>>>> Kay >>>>>>>>=20 >>>>>>>> Privacy matters! We know from recent events that people are >>>>>>>> using our >>>>>>> services to speak in defiance of unjust governments. We treat >>>>> privacy >>>>>>> and security as matters of life and death, because for some >>>>>>> users, they are. >>>>>>>> _______________________________________________ >>>>>>>> lmap mailing list >>>>>>>> lmap@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lmap >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> lmap mailing list >>>>>>> lmap@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lmap >>>>>>=20 >>>>>> _______________________________________________ >>>>>> lmap mailing list >>>>>> lmap@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_D7E348F1-5BBD-4D40-BA5D-BC175837E17A 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 iQEcBAEBCgAGBQJTH3QzAAoJENt3nsOmbNJcqbYIANYxOudSKZg0cd19Io3YNP/k Tl/xeHEizkg1tp0IoHzj4wgyFJ/kSX/izUyBzkiVJJd5lXOKbSK2UPYg/4gWJ0f7 6P/H6DyTd8fV9Jypuk4Dj9IjkGoW//1sjS3BdNQjfaXhxW2ObSKo9+rJA5uIpgJH hhUqXaptxjWg9guzlVqB1bcRfzDbeHHvaEnxNml8UGxuHEnZGysCzI/JXbSzYOYD fW8aOOcTyTruDOnAY5YBsMdOGpjedS9SyOXA368NpXQb8nLwFMrl89JuzC5y99qz CN8oDs3vegubzIQd0XelorU6uqjiK96ChxEM+nuzCZB39dSdcQh3VAssoNfa4Tg= =kAMS -----END PGP SIGNATURE----- --Apple-Mail=_D7E348F1-5BBD-4D40-BA5D-BC175837E17A-- From nobody Tue Mar 11 23:54:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110B11A08F1 for ; Tue, 11 Mar 2014 23:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 b88BpAFeQqjr for ; Tue, 11 Mar 2014 23:54:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E20AB1A0641 for ; Tue, 11 Mar 2014 23:54:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E3E7110A; Wed, 12 Mar 2014 07:54:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oiwvjlADhRd1; Wed, 12 Mar 2014 07:54:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 12 Mar 2014 07:54:00 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2FFB2002F; Wed, 12 Mar 2014 07:54:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m-tZdH7aDTXm; Wed, 12 Mar 2014 07:54:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D9212002C; Wed, 12 Mar 2014 07:53:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CDD152BB17B2; Wed, 12 Mar 2014 07:53:57 +0100 (CET) Date: Wed, 12 Mar 2014 07:53:57 +0100 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20140312065357.GB82765@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , "'Romascanu, Dan (Dan)'" , "'MORTON, ALFRED C (AL)'" , 'Brian Trammell' , 'Matt Mathis' , "'lmap@ietf.org'" References: <98184277-C341-4622-ABED-990702554F8C@trammell.ch> <2845723087023D4CB5114223779FA9C80178CEF240@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E4538DA@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2DF@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A16@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF2E5@njfpsrvexg8.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA2E453A81@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hjl_mO0oceCTjjs_ZJ5OTdP6nBs Cc: "'Romascanu, Dan \(Dan\)'" , 'Matt Mathis' , "'MORTON, ALFRED C \(AL\)'" , "'lmap@ietf.org'" , 'Brian Trammell' Subject: Re: [lmap] clarrification -- RE: One example of a "passive measurement peer" 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, 12 Mar 2014 06:54:10 -0000 On Tue, Mar 11, 2014 at 06:11:08PM +0000, Bugenhagen, Michael K wrote: > Suggestion / proposal for responder types / layers > > In terms of Agent / Responder types... I think we'd have to decompose the agent / responders to the following levels. > [...] I do not think any decomposition is needed for doing the LMAP work in the IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Mar 12 01:52:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63571A0927 for ; Wed, 12 Mar 2014 01:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcDjgTpRrPWx for ; Wed, 12 Mar 2014 01:52:21 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id D9EEE1A091D for ; Wed, 12 Mar 2014 01:52:20 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 12 Mar 2014 08:52:22 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 12 Mar 2014 08:52:13 +0000 From: To: Date: Wed, 12 Mar 2014 08:52:11 +0000 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt Thread-Index: Ac89UtLeO4zfofxfS760Hr4yFJJmdQAfXZ7A Message-ID: References: <20140216152054.6394.98581.idtracker@ietfa.amsl.com> <531F44A7.8010604@centurylink.com> <531F4D92.3090806@centurylink.com> In-Reply-To: <531F4D92.3090806@centurylink.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/A2G92HOMesBDYRJ4bvKdhJiOkq8 Cc: lmap@ietf.org Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 08:52:25 -0000 That's correct - will clarify on the next edit. >-----Original Message----- >From: Charles Cook [mailto:charles.cook2@centurylink.com] >Sent: 11 March 2014 17:53 >To: Burbridge,T,Trevor,TUB8 R >Cc: lmap@ietf.org >Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-00.txt > >Trevor, > >Thanks for the clarifications. > >One more question regarding the serialization of the Measurement Tasks. >When you say "in order", do you mean in order as they were sent to the MA,= or >do you mean in order as they are scheduled? I assume it is that later, bu= t without >that clarification in the draft some may think the former. For example, t= he >Controller could send Measurement Tasks A, B, and C in that order. But wh= en >you look at the Measurement Schedule it may say do B first, followed by C, >followed by A. Now we have an ambiguity. That is why I think what we rea= lly >want to say is that the Measurement Tasks will be executed "in order based= on >the Measurement Schedule". Let me know if I am missing something. > >Charles > >On 3/11/2014 11:26 AM, trevor.burbridge@bt.com wrote: >> Thanks for the comments Charles. >> >> Some of these were covered in the suggested updates during the IETF LMAP >session, but see inline for answers.... >> >>> -----Original Message----- >>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook >>> Sent: 11 March 2014 17:15 >>> To: lmap@ietf.org >>> Subject: Re: [lmap] I-D Action: >>> draft-ietf-lmap-information-model-00.txt >>> >>> I finally got around to reviewing the Information Model. Attached >>> are my comments. >>> >>> In summary: >>> >>> It appears that the Information Channel is being referenced with Pre- >>> configuration information rather than Configuration information. >>> Pre-configuration information cannot be provided via the Information >>> Channel because the MA has to register with the Controller before it >>> can receive Configuration information from the Controller. >> We're going to make the whole concept of channels a lot simpler. In the = pre- >config the MA will need an initial channel to contact the Controller. We n= o longer >bind this channel to specific types of data (config, instruction, capabili= ties, >logging etc.) or to a specific timing. Any channel will simply become a se= cure >communication channel to an end-point. >> >> Hopefully will make things a lot clearer (and also more flexible). >> >>> There is a reference that Measurement Tasks will be executed "in order" >>> which may imply "serially" to some. It would be more accurate to say >>> executed per the Measurement Schedule. >> It does say that, and we did indeed mean serialised! We wanted the abili= ty to >specify a non-overlapping list of things to do in a single schedule. If yo= u want to >overlap then use multiple schedules. >> >>> At one time I thought I heard that one of the "Elements" may be split >>> into two Elements. If that happens, the draft will need to be updated. >>> Given the recent discussion on Active vs Passive, maybe that is no >>> longer under consideration. >> I think this was probably the one-off vs. repeated tasks. We agreed the >information model does not need to split these (other than by the use of d= ifferent >timing objects). It is up to the protocol implementation into whether one-= off and >repeated tests are updated separately (or indeed any breakdown of the >instruction). >> >>> Regarding Operational Update messages, consideration should be given >>> to a "Scheduling conflict" message. This may also need to be >>> mentioned in Section >>> 3.7 "Reporting Information". >> Yes, I discussed on the last slide that we need further discussion on th= e >reporting of test collisions. >> >>> There were also a few editorial items. >> Will make sure we catch them in the forthcoming 01 edit. >> >>> Overall, it is looking good. >> Thanks! >> >>> Charles >> Trevor. >> >>> On 2/16/2014 8:20 AM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> 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 Measuremen= t Platforms >>> (LMAP) >>>> Authors : Trevor Burbridge >>>> Philip Eardley >>>> Marcelo Bagnulo >>>> Juergen Schoenwaelder >>>> Filename : draft-ietf-lmap-information-model-00.txt >>>> Pages : 21 >>>> Date : 2014-02-14 >>>> >>>> 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-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/ >>>> >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>>> >>> -- >>> >>> Charles Cook >>> Principal Architect >>> Network >>> 5325 Zuni Street; Suite 224 >>> Denver, CO 80221 >>> Tel: 303.992.8952 Fax: 925.281.0662 charles.cook2@centurylink.com >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > >-- > >Charles Cook >Principal Architect >Network >5325 Zuni Street; Suite 224 >Denver, CO 80221 >Tel: 303.992.8952 Fax: 925.281.0662 >charles.cook2@centurylink.com From nobody Thu Mar 13 02:20:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E882A1A092C for ; Thu, 13 Mar 2014 02:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJD_jKeaSyWr for ; Thu, 13 Mar 2014 02:20:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B7EFA1A0928 for ; Thu, 13 Mar 2014 02:20:22 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 09:18:51 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 13 Mar 2014 09:19:46 +0000 From: To: Date: Thu, 13 Mar 2014 09:19:45 +0000 Thread-Topic: Information Model proposed changes Thread-Index: Ac8+nV+oJlpE/Nu8So2esA6D2NFfsw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/puCydGlzrMghvvS3kOvsddYSPEU Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, j.schoenwaelder@jacobs-university.de Subject: [lmap] Information Model proposed 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: Thu, 13 Mar 2014 09:20:25 -0000 As presented and discussed at IETF 89, unless we hear contrary opinions we = plan to make the following changes in the next week: 1) Channels no longer have timing information. This allows the channel to j= ust specify an endpoint and security credentials. What data is to be sent t= o the channel and when is left to Tasks. Tasks become more generic encompas= sing any scheduled logic running on the MA. In addition to Measurement Task= s, Tasks will also batch results and send data to/from the channels etc. Ta= sks can output to other Tasks (e.g. to batch results) or to Channels. For e= xample, updating the Instruction becomes a scheduled Task. As does error re= porting or updating capabilities. For further information see the IETF slid= es. 2) Reports no longer have context information in the Report header. The ori= ginal purpose was to report device and network context such as line speed. = This responsibility is now devolved to Tasks and as such the information wi= ll be reported in the Task result data within the Report. Each Measurement = tasks can either report the context application to itself, or tasks specifi= cally designed to gather and report such context can be used. This approach= seems clearer and there is no longer any ambiguity about then the context = was valid. 3) Suppression information to include one further Boolean "Stop Current Tas= ks". If set the MA will terminate already executing Tasks in addition to st= opping the commencement of new scheduled Tasks. Trevor. From nobody Thu Mar 13 02:25:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA111A0924 for ; Thu, 13 Mar 2014 02:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru1GGPN4iMVN for ; Thu, 13 Mar 2014 02:25:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 09E351A0922 for ; Thu, 13 Mar 2014 02:25:15 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 09:23:45 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Thu, 13 Mar 2014 09:24:58 +0000 From: To: Date: Thu, 13 Mar 2014 09:24:57 +0000 Thread-Topic: Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8w== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/gCnrLGl4TnfVc3tFcl4x_Jy56Ow Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, j.schoenwaelder@jacobs-university.de Subject: [lmap] Information Model - Interface classification 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, 13 Mar 2014 09:25:19 -0000 We discussed at IETF 89 the possibility of classifying interfaces and being= able to use such classes in the Task or Channel configuration. For example= , instead of having to specify ppp0 we might be able to say "active WAN". O= ther classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. While this seems sensible, does anyone know of existing interface ontologie= s that are used elsewhere in the IETF or wider industry that we could learn= from or reference? Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of >trevor.burbridge@bt.com >Sent: 13 March 2014 09:20 >To: lmap@ietf.org >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; j.schoenwaelder@jacobs- >university.de >Subject: [lmap] Information Model proposed changes > >As presented and discussed at IETF 89, unless we hear contrary opinions we= plan >to make the following changes in the next week: > >1) Channels no longer have timing information. This allows the channel to = just >specify an endpoint and security credentials. What data is to be sent to t= he >channel and when is left to Tasks. Tasks become more generic encompassing = any >scheduled logic running on the MA. In addition to Measurement Tasks, Tasks= will >also batch results and send data to/from the channels etc. Tasks can outpu= t to >other Tasks (e.g. to batch results) or to Channels. For example, updating = the >Instruction becomes a scheduled Task. As does error reporting or updating >capabilities. For further information see the IETF slides. > >2) Reports no longer have context information in the Report header. The or= iginal >purpose was to report device and network context such as line speed. This >responsibility is now devolved to Tasks and as such the information will b= e >reported in the Task result data within the Report. Each Measurement tasks= can >either report the context application to itself, or tasks specifically des= igned to >gather and report such context can be used. This approach seems clearer an= d >there is no longer any ambiguity about then the context was valid. > >3) Suppression information to include one further Boolean "Stop Current Ta= sks". >If set the MA will terminate already executing Tasks in addition to stoppi= ng the >commencement of new scheduled Tasks. > >Trevor. > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 13 02:36:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E21A093D for ; Thu, 13 Mar 2014 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qcMpnWHCkJG for ; Thu, 13 Mar 2014 02:36:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id B3F701A093C for ; Thu, 13 Mar 2014 02:36:09 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 09:36:13 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 13 Mar 2014 09:36:01 +0000 From: To: Date: Thu, 13 Mar 2014 09:36:00 +0000 Thread-Topic: Information Model - Reporting Task collisions/interference Thread-Index: Ac8+n6B7u9m4+TudSvi4UXJ6XT41/g== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/--bMHD4tB84ZU3D1Mh01WXKyFkc Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, j.schoenwaelder@jacobs-university.de Subject: [lmap] Information Model - Reporting Task collisions/interference 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, 13 Mar 2014 09:36:11 -0000 At IETF 89 we also discussed the requirement to be able to report if a Meas= urement Task may have conflicted with another Task. While this could be as = simple as a Boolean in the Report for each Task, we could potentially consi= der something more complicated. Since a Boolean would not tell us which Tas= ks were operating concurrently and whether there might be cause for concern= (e.g. it could be a permanently running error reporting task or a passive = analysis task). Therefore it seems likely that we want to discuss two approaches: 1) listing the Tasks that overlapped with the execution of the reporting Ta= sk. Simple conceptually and gives the most information to the person/system= analysing results. 2) Attempt to classify Tasks by their potential conflict and report a confl= ict level. E.g. colliding with a passive tasks might be conflict level 1, b= ut colliding with a TCP throughput test might be conflict level 5. Personal= ly I'd be very much against such an approach as (a) I don't want to classif= y Tasks and (b) It's not really possible to give a general conflict rating = to a Task since it will affect different other Tasks to different levels. So do people think 1) is the way forward? Shall we add "Conflicting Tasks" = (as a List of Task Names) to the Task header information in the Report? Trevor From nobody Thu Mar 13 02:36:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B01A0922 for ; Thu, 13 Mar 2014 02:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 9tjFL-kt-QY9 for ; Thu, 13 Mar 2014 02:36:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 82BCE1A090B for ; Thu, 13 Mar 2014 02:36:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2E011120; Thu, 13 Mar 2014 10:36:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Kz52PEfB5xa9; Thu, 13 Mar 2014 10:36:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 13 Mar 2014 10:36:49 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A1202002C; Thu, 13 Mar 2014 10:36:49 +0100 (CET) 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 EQ9hPUbieY2J; Thu, 13 Mar 2014 10:36:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 561DD2002F; Thu, 13 Mar 2014 10:36:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 82A652BB31D1; Thu, 13 Mar 2014 10:36:46 +0100 (CET) Date: Thu, 13 Mar 2014 10:36:45 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140313093644.GB85809@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org, marcelo@it.uc3m.es, philip.eardley@bt.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/y3pZm3-EddGxAVG0q_WfAOXoHT8 Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 09:36:58 -0000 On Thu, Mar 13, 2014 at 09:24:57AM +0000, trevor.burbridge@bt.com wrote: > We discussed at IETF 89 the possibility of classifying interfaces and being able to use such classes in the Task or Channel configuration. For example, instead of having to specify ppp0 we might be able to say "active WAN". Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > > While this seems sensible, does anyone know of existing interface ontologies that are used elsewhere in the IETF or wider industry that we could learn from or reference? > IANA has an interface type registry [1]. Of course, these interface types are technology specific. Things like "active WAN" are usage specific classifications and the question is whether devices can be trusted to determine them correctly. /js [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib -- 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 Mar 13 02:40:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F021A0922 for ; Thu, 13 Mar 2014 02:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 vleiQPs5Do3a for ; Thu, 13 Mar 2014 02:39:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B71A090B for ; Thu, 13 Mar 2014 02:39:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2E981143; Thu, 13 Mar 2014 10:39:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HOqtfrWSqLfy; Thu, 13 Mar 2014 10:39:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 13 Mar 2014 10:39:51 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 435262002F; Thu, 13 Mar 2014 10:39:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FVkY5dz_0i9J; Thu, 13 Mar 2014 10:39:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34ED12002C; Thu, 13 Mar 2014 10:39:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6D3612BB322C; Thu, 13 Mar 2014 10:39:48 +0100 (CET) Date: Thu, 13 Mar 2014 10:39:47 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20140313093947.GC85809@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org, marcelo@it.uc3m.es, philip.eardley@bt.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/mpk9_H5HHiWNXSZEv_qKF3tMJno Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model - Reporting Task collisions/interference 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, 13 Mar 2014 09:40:01 -0000 On Thu, Mar 13, 2014 at 09:36:00AM +0000, trevor.burbridge@bt.com wrote: > At IETF 89 we also discussed the requirement to be able to report if a Measurement Task may have conflicted with another Task. While this could be as simple as a Boolean in the Report for each Task, we could potentially consider something more complicated. Since a Boolean would not tell us which Tasks were operating concurrently and whether there might be cause for concern (e.g. it could be a permanently running error reporting task or a passive analysis task). > > Therefore it seems likely that we want to discuss two approaches: > 1) listing the Tasks that overlapped with the execution of the reporting Task. Simple conceptually and gives the most information to the person/system analysing results. > 2) Attempt to classify Tasks by their potential conflict and report a conflict level. E.g. colliding with a passive tasks might be conflict level 1, but colliding with a TCP throughput test might be conflict level 5. Personally I'd be very much against such an approach as (a) I don't want to classify Tasks and (b) It's not really possible to give a general conflict rating to a Task since it will affect different other Tasks to different levels. > > So do people think 1) is the way forward? Shall we add "Conflicting Tasks" (as a List of Task Names) to the Task header information in the Report? > I agree that 2) is wishful thinking. I am also concerned to add noise to every report in cases where it is not needed. So this conflict report should be optional so that in cases where this is really not needed, you can save the noise in the report channel. /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 Mar 13 04:17:43 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF42B1A095C for ; Thu, 13 Mar 2014 04:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 w5GdJq1a_hfZ for ; Thu, 13 Mar 2014 04:17:39 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id A96FA1A0950 for ; Thu, 13 Mar 2014 04:17:39 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id dc391235.2b5d4d401940.3623325.00-2464.10173476.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 13 Mar 2014 11:17:33 +0000 (UTC) X-MXL-Hash: 532193cd53a4e035-50369eab371dbcca7d8c2bf4455d826edd3f55eb Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9c391235.0.3623313.00-2188.10173439.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 13 Mar 2014 11:17:32 +0000 (UTC) X-MXL-Hash: 532193cc4b117b4a-5044bdbd831431b36af9218088225e2e0ef3b2de 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 s2DBHT2U020799; Thu, 13 Mar 2014 07:17:29 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2DBHINw020751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 07:17:21 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 13 Mar 2014 11:17:11 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 07:17:11 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "trevor.burbridge@bt.com" Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8wAIy8mAAAXR3LA= Date: Thu, 13 Mar 2014 11:17:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140313093644.GB85809@elstar.local> In-Reply-To: <20140313093644.GB85809@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.139.81] 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=IZIwrxWa c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=qk9TuhsUrScA:10 a=ofMgfj31e3cA:10 a=OYUKPaRJwSIA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=I0CVDw5ZAAAA:8 a=CfmqLWV822IOYmH23s0A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/HKJvu36txfONVp_Tbzqyv7w11ko Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 11:17:42 -0000 > > We discussed at IETF 89 the possibility of classifying interfaces and b= eing > able to use such classes in the Task or Channel configuration. For exampl= e, > instead of having to specify ppp0 we might be able to say "active WAN". > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > > > > While this seems sensible, does anyone know of existing interface > ontologies that are used elsewhere in the IETF or wider industry that we > could learn from or reference? > > >=20 > IANA has an interface type registry [1]. Of course, these interface types= are > technology specific. Things like "active WAN" are usage specific classifi= cations > and the question is whether devices can be trusted to determine them > correctly. >=20 > /js >=20 > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib Every time I've participated in a discussion about "standard ways of expres= sing interfaces" (many instances of such discussions, in various groups), w= e've always looked at this IANA registry and determined that it's useless f= or this purpose. In every case, the people ended up either (1) defining the= ir own enumerated list or (2) don't standardize and just accept whatever na= mes the underlying OS applies to the interface (i.e., no classifying). When the devices are largely homogeneous or of a limited set of different d= evices, using the OS name is workable. The reason the IANA list has been found useless for these purposes in the p= ast is because the interfaces in this registry are at all layers and some a= re not sufficiently specific (e.g., ieee80211 is used for all variants -- a= , b, g, n, ac; and a device with multiple radios, for example operating at = 2.4 and 5 GHz would get the same classification). The fact that they are at= all layers presents ambiguity if an interface is specific that has multipl= e IP interfaces riding over it. There is no ability in it to distinguish di= fferent IP interfaces.=20 For example, a "telco broadband" "residential gateway" can have (1) a manag= ement IP interface, (2) a default route "Internet service" IP interface, (3= ) an IPTV IP interface, and (4) a VoIP IP interface. All of these may go ov= er a single DSL, PON, or Ethernet (PHY) interface. They may be done using s= eparate ATM interfaces (not likely anymore, but done at one time), separate= PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer), separate = IP "default router" routes, or separate tunnels over a single IP routed int= erface. And that's just the WAN. On the LAN, we have RGs with multiple Wi-F= i radios operating at different frequencies and being used for different pu= rposes. So asking such a device to test over its "Wi-Fi" interface is ambig= uous. "LAN" is even more ambiguous.=20 If the group would like, I can put together and provide you with informatio= n on how various groups have tried to solve this sort of thing, based on pu= blicly available docs. Maybe this would be useful insight. Barbara=20 From nobody Thu Mar 13 04:21:25 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8791A095F for ; Thu, 13 Mar 2014 04:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 g39yLtBG91Br for ; Thu, 13 Mar 2014 04:21:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3D30A1A095C for ; Thu, 13 Mar 2014 04:21:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAOGTIVPGmAcV/2dsb2JhbABZgmUhO1eobpEqG4cugRoWdIIlAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQsUCQcnCxQJCAEBBAENBQgBGYdXAQynQ6wgF4xvgRYnMQcGgx6BFASfOYNxh0iDLYFpQg X-IronPort-AV: E=Sophos;i="4.97,646,1389762000"; d="scan'208";a="53471913" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Mar 2014 07:21:13 -0400 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; 13 Mar 2014 07:08:08 -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, 13 Mar 2014 07:21:11 -0400 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , Juergen Schoenwaelder , "trevor.burbridge@bt.com" Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8///8oyAgAAcDgD//+7PcA== Date: Thu, 13 Mar 2014 11:21:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zkTYnguMl0ExQ9zBUaO_BveZr7Y Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 11:21:22 -0000 Hi, I am wondering what is the practical purpose or benefit of this classificat= ion for LMAP. Does it change any bits on wire, protocol fields, location or= organization of IANA registry?=20 Can somebody explain?=20 Thanks and Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Thursday, March 13, 2014 1:17 PM > To: Juergen Schoenwaelder; trevor.burbridge@bt.com > Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] Information Model - Interface classification >=20 > > > We discussed at IETF 89 the possibility of classifying interfaces > > > and being > > able to use such classes in the Task or Channel configuration. For > > example, instead of having to specify ppp0 we might be able to say "act= ive > WAN". > > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > > > > > > While this seems sensible, does anyone know of existing interface > > ontologies that are used elsewhere in the IETF or wider industry that > > we could learn from or reference? > > > > > > > IANA has an interface type registry [1]. Of course, these interface > > types are technology specific. Things like "active WAN" are usage > > specific classifications and the question is whether devices can be > > trusted to determine them correctly. > > > > /js > > > > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib >=20 > Every time I've participated in a discussion about "standard ways of > expressing interfaces" (many instances of such discussions, in various > groups), we've always looked at this IANA registry and determined that it= 's > useless for this purpose. In every case, the people ended up either (1) > defining their own enumerated list or (2) don't standardize and just acce= pt > whatever names the underlying OS applies to the interface (i.e., no > classifying). >=20 > When the devices are largely homogeneous or of a limited set of different > devices, using the OS name is workable. >=20 > The reason the IANA list has been found useless for these purposes in the > past is because the interfaces in this registry are at all layers and som= e are > not sufficiently specific (e.g., ieee80211 is used for all variants -- a,= b, g, n, ac; > and a device with multiple radios, for example operating at 2.4 and 5 GHz > would get the same classification). The fact that they are at all layers = presents > ambiguity if an interface is specific that has multiple IP interfaces rid= ing over > it. There is no ability in it to distinguish different IP interfaces. >=20 > For example, a "telco broadband" "residential gateway" can have (1) a > management IP interface, (2) a default route "Internet service" IP interf= ace, > (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may g= o over a > single DSL, PON, or Ethernet (PHY) interface. They may be done using > separate ATM interfaces (not likely anymore, but done at one time), > separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer), > separate IP "default router" routes, or separate tunnels over a single IP > routed interface. And that's just the WAN. On the LAN, we have RGs with > multiple Wi-Fi radios operating at different frequencies and being used f= or > different purposes. So asking such a device to test over its "Wi-Fi" inte= rface is > ambiguous. "LAN" is even more ambiguous. >=20 > If the group would like, I can put together and provide you with informat= ion > on how various groups have tried to solve this sort of thing, based on pu= blicly > available docs. Maybe this would be useful insight. > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 13 04:29:59 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB221A09D6 for ; Thu, 13 Mar 2014 04:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwg3x_Y7-KZt for ; Thu, 13 Mar 2014 04:29:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5806A1A095F for ; Thu, 13 Mar 2014 04:29:51 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 11:28:21 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 13 Mar 2014 11:29:26 +0000 From: To: , , Date: Thu, 13 Mar 2014 11:29:25 +0000 Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8///8oyAgAAcDgD//+7PcP//26XA Message-ID: References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bav-j1pPEbixrX0Wd6UqduNKJrI Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 11:29:56 -0000 Yes. The Information Model allows the specification of an Interface as eith= er a Task or Channel parameter. At the moment this is a string (no suggeste= d change) and expresses a device interface (e.g. eth1, ppp0 etc.). While th= e structure of the Information model does not need to change we do need to = say what data can be present in those strings. E.g. if a Controller says "A= ctive WAN" as an alias then the MA needs to know what the Controller means = by this. This does need to be standardised (if we allow such aliases) or re= ferenced to existing definitions. Trevor. >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan= ) >Sent: 13 March 2014 11:21 >To: STARK, BARBARA H; Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; lmap@ietf.org >Subject: Re: [lmap] Information Model - Interface classification > >Hi, > >I am wondering what is the practical purpose or benefit of this classifica= tion for >LMAP. Does it change any bits on wire, protocol fields, location or organi= zation >of IANA registry? > >Can somebody explain? > >Thanks and Regards, > >Dan > > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H >> Sent: Thursday, March 13, 2014 1:17 PM >> To: Juergen Schoenwaelder; trevor.burbridge@bt.com >> Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org >> Subject: Re: [lmap] Information Model - Interface classification >> >> > > We discussed at IETF 89 the possibility of classifying interfaces >> > > and being >> > able to use such classes in the Task or Channel configuration. For >> > example, instead of having to specify ppp0 we might be able to say "ac= tive >> WAN". >> > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. >> > > >> > > While this seems sensible, does anyone know of existing interface >> > ontologies that are used elsewhere in the IETF or wider industry that >> > we could learn from or reference? >> > > >> > >> > IANA has an interface type registry [1]. Of course, these interface >> > types are technology specific. Things like "active WAN" are usage >> > specific classifications and the question is whether devices can be >> > trusted to determine them correctly. >> > >> > /js >> > >> > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib >> >> Every time I've participated in a discussion about "standard ways of >> expressing interfaces" (many instances of such discussions, in various >> groups), we've always looked at this IANA registry and determined that i= t's >> useless for this purpose. In every case, the people ended up either (1) >> defining their own enumerated list or (2) don't standardize and just acc= ept >> whatever names the underlying OS applies to the interface (i.e., no >> classifying). >> >> When the devices are largely homogeneous or of a limited set of differen= t >> devices, using the OS name is workable. >> >> The reason the IANA list has been found useless for these purposes in th= e >> past is because the interfaces in this registry are at all layers and so= me are >> not sufficiently specific (e.g., ieee80211 is used for all variants -- a= , b, g, n, ac; >> and a device with multiple radios, for example operating at 2.4 and 5 GH= z >> would get the same classification). The fact that they are at all layers= presents >> ambiguity if an interface is specific that has multiple IP interfaces ri= ding over >> it. There is no ability in it to distinguish different IP interfaces. >> >> For example, a "telco broadband" "residential gateway" can have (1) a >> management IP interface, (2) a default route "Internet service" IP inter= face, >> (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may = go over a >> single DSL, PON, or Ethernet (PHY) interface. They may be done using >> separate ATM interfaces (not likely anymore, but done at one time), >> separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer)= , >> separate IP "default router" routes, or separate tunnels over a single I= P >> routed interface. And that's just the WAN. On the LAN, we have RGs with >> multiple Wi-Fi radios operating at different frequencies and being used = for >> different purposes. So asking such a device to test over its "Wi-Fi" int= erface is >> ambiguous. "LAN" is even more ambiguous. >> >> If the group would like, I can put together and provide you with informa= tion >> on how various groups have tried to solve this sort of thing, based on p= ublicly >> available docs. Maybe this would be useful insight. >> Barbara >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 13 05:46:57 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139851A07FA for ; Thu, 13 Mar 2014 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 oAGClMhd24g1 for ; Thu, 13 Mar 2014 05:46:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 159531A07BE for ; Thu, 13 Mar 2014 05:46:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CEF5F1146; Thu, 13 Mar 2014 13:46:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id llnWXWxzU_5j; Thu, 13 Mar 2014 13:46:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 13 Mar 2014 13:46:42 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 594E920033; Thu, 13 Mar 2014 13:46:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HPghkSjwQfVP; Thu, 13 Mar 2014 13:46:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB17A2002F; Thu, 13 Mar 2014 13:46:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7D0972BC52D6; Thu, 13 Mar 2014 13:46:38 +0100 (CET) Date: Thu, 13 Mar 2014 13:46:38 +0100 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140313124638.GA86609@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "trevor.burbridge@bt.com" , "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/dkPzwyeDkqZcUTetHz-izyOwx6w Cc: "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 12:46:55 -0000 On Thu, Mar 13, 2014 at 11:17:10AM +0000, STARK, BARBARA H wrote: > > > We discussed at IETF 89 the possibility of classifying interfaces and being > > able to use such classes in the Task or Channel configuration. For example, > > instead of having to specify ppp0 we might be able to say "active WAN". > > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > > > > > > While this seems sensible, does anyone know of existing interface > > ontologies that are used elsewhere in the IETF or wider industry that we > > could learn from or reference? > > > > > > > IANA has an interface type registry [1]. Of course, these interface types are > > technology specific. Things like "active WAN" are usage specific classifications > > and the question is whether devices can be trusted to determine them > > correctly. > > > > /js > > > > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib > > Every time I've participated in a discussion about "standard ways of expressing interfaces" (many instances of such discussions, in various groups), we've always looked at this IANA registry and determined that it's useless for this purpose. In every case, the people ended up either (1) defining their own enumerated list or (2) don't standardize and just accept whatever names the underlying OS applies to the interface (i.e., no classifying). > > When the devices are largely homogeneous or of a limited set of different devices, using the OS name is workable. Please do not confuse interface type with interface name. These are separate things although they are often related since several OSes use an interface naming scheme that carries some type information. > The reason the IANA list has been found useless for these purposes in the past is because the interfaces in this registry are at all layers and some are not sufficiently specific (e.g., ieee80211 is used for all variants -- a, b, g, n, ac; and a device with multiple radios, for example operating at 2.4 and 5 GHz would get the same classification). The fact that they are at all layers presents ambiguity if an interface is specific that has multiple IP interfaces riding over it. There is no ability in it to distinguish different IP interfaces. While I da agree that the IANA registry is far from being perfect, it depends on the layer whether differences are visible or not. There is usually a stack of interfaces layers and yes not all devices expose them and yet not all layers are properly registered within IANA. But then it is also not clear in some cases what is another layer and what is not. > For example, a "telco broadband" "residential gateway" can have (1) a management IP interface, (2) a default route "Internet service" IP interface, (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may go over a single DSL, PON, or Ethernet (PHY) interface. They may be done using separate ATM interfaces (not likely anymore, but done at one time), separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer), separate IP "default router" routes, or separate tunnels over a single IP routed interface. And that's just the WAN. On the LAN, we have RGs with multiple Wi-Fi radios operating at different frequencies and being used for different purposes. So asking such a device to test over its "Wi-Fi" interface is ambiguous. "LAN" is even more ambiguous. > Exactly. And this is why I believe this problem is too hard to solve. Lets stay aware from it. > If the group would like, I can put together and provide you with information on how various groups have tried to solve this sort of thing, based on publicly available docs. Maybe this would be useful insight. Did anyone solve the problem or did they all only try to solve it? In the later case, I do not need to see the details. ;-) /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 Mar 13 06:07:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81561A08B0 for ; Thu, 13 Mar 2014 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 F8qcSijuWzco for ; Thu, 13 Mar 2014 06:07:22 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AC3741A088A for ; Thu, 13 Mar 2014 06:07:22 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 48da1235.2b3adc693940.2677665.00-2476.7041104.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Mar 2014 13:07:16 +0000 (UTC) X-MXL-Hash: 5321ad84061494e7-6bb33373612c6ff2a4fa58321c8b5c9595d91772 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 18da1235.0.2677642.00-2388.7041027.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 13 Mar 2014 13:07:15 +0000 (UTC) X-MXL-Hash: 5321ad8313ee7188-d6be00ca29d2f2a5fe807e1580468ab86b357c8b 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 s2DD7Djx011260; Thu, 13 Mar 2014 09:07:13 -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 s2DD72Uv011134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 09:07:06 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 13 Mar 2014 13:06:48 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 09:06:48 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8wAIy8mAAAXR3LAAAM/VAAAH81mw Date: Thu, 13 Mar 2014 13:06:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113040AD3A@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140313124638.GA86609@elstar.local> In-Reply-To: <20140313124638.GA86609@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.19.24] 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=LqUlPAhc c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=qk9TuhsUrScA:10 a=ofMgfj31e3cA:10 a=DTE4Nt6yI8sA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=g2VuHAZgzJMy_ACZ01sA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3F3ndYZPeImevXlydRSvE4EQjLU Cc: "marcelo@it.uc3m.es" , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 13:07:24 -0000 > > For example, a "telco broadband" "residential gateway" can have (1) a > management IP interface, (2) a default route "Internet service" IP interf= ace, > (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may g= o over a > single DSL, PON, or Ethernet (PHY) interface. They may be done using > separate ATM interfaces (not likely anymore, but done at one time), > separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer), > separate IP "default router" routes, or separate tunnels over a single IP > routed interface. And that's just the WAN. On the LAN, we have RGs with > multiple Wi-Fi radios operating at different frequencies and being used f= or > different purposes. So asking such a device to test over its "Wi-Fi" inte= rface is > ambiguous. "LAN" is even more ambiguous. > > >=20 > Exactly. And this is why I believe this problem is too hard to solve. Let= s stay > aware from it. Agreed regarding generic classification. But I wasn't an advocate of that i= n the first place. I didn't argue against it very strongly because it seeme= d better to let people explore the question and come to their own conclusio= ns. I'm thinking there may be something we can do to better model interface= info.=20 =20 > > If the group would like, I can put together and provide you with > information on how various groups have tried to solve this sort of thing, > based on publicly available docs. Maybe this would be useful insight. >=20 > Did anyone solve the problem or did they all only try to solve it? In the= later > case, I do not need to see the details. ;-) >=20 > /js Fair enough. Whether the problem was "solved" is a matter of opinion and de= gree (e.g.., somewhat solved, good enough, etc.). I'll try my best not to p= rovide details of anything that I consider inadequate. Barbara From nobody Thu Mar 13 06:09:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43721A08B0 for ; Thu, 13 Mar 2014 06:09:38 -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 pkegcowdkaJO for ; Thu, 13 Mar 2014 06:09:37 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 041F61A082B for ; Thu, 13 Mar 2014 06:09:36 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2DD9Qcr019658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2014 07:09:26 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2744C1E007F; Thu, 13 Mar 2014 08:09:21 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 108D81E006F; Thu, 13 Mar 2014 08:09:21 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2DD9JP1024674; Thu, 13 Mar 2014 08:09:19 -0500 (CDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s2DD9I8B024554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Mar 2014 08:09:19 -0500 (CDT) Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([2002:9775:ce1c::9775:ce1c]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 08:09:18 -0500 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" , "'trevor.burbridge@bt.com'" Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8wAK5DqAAAMT07A= Date: Thu, 13 Mar 2014 13:09:17 +0000 Message-ID: References: <20140313093644.GB85809@elstar.local> In-Reply-To: <20140313093644.GB85809@elstar.local> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/BIWPTzIB2qk-QOiocMmjP7qH5_M Cc: "'marcelo@it.uc3m.es'" , "'philip.eardley@bt.com'" , "'lmap@ietf.org'" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 13:09:39 -0000 UNI =3D Network User Interface That is the highest abstraction level for a customer interface. Make sure you allow more than 1 of those per device. Mike -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Thursday, March 13, 2014 4:37 AM To: trevor.burbridge@bt.com Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model - Interface classification On Thu, Mar 13, 2014 at 09:24:57AM +0000, trevor.burbridge@bt.com wrote: > We discussed at IETF 89 the possibility of classifying interfaces and bei= ng able to use such classes in the Task or Channel configuration. For examp= le, instead of having to specify ppp0 we might be able to say "active WAN".= Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. >=20 > While this seems sensible, does anyone know of existing interface ontolog= ies that are used elsewhere in the IETF or wider industry that we could lea= rn from or reference? >=20 IANA has an interface type registry [1]. Of course, these interface types a= re technology specific. Things like "active WAN" are usage specific classif= ications and the question is whether devices can be trusted to determine th= em correctly. /js [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib --=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 Thu Mar 13 06:28:07 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1EA1A07F6 for ; Thu, 13 Mar 2014 06:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 riRJ1QyMd6yT for ; Thu, 13 Mar 2014 06:28:03 -0700 (PDT) Received: from nm5-vm4.access.bullet.mail.gq1.yahoo.com (nm5-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.93]) by ietfa.amsl.com (Postfix) with ESMTP id 23E111A07CD for ; Thu, 13 Mar 2014 06:28:03 -0700 (PDT) Received: from [216.39.60.171] by nm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Mar 2014 13:27:56 -0000 Received: from [216.39.60.231] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Mar 2014 13:27:56 -0000 Received: from [127.0.0.1] by omp1002.access.mail.gq1.yahoo.com with NNFMP; 13 Mar 2014 13:27:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 869029.24251.bm@omp1002.access.mail.gq1.yahoo.com Received: (qmail 78817 invoked by uid 60001); 13 Mar 2014 13:27:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394717276; bh=GREBQfYAWHy7jcWGyv3EAvzc1lAFu6Yx0wfQK5IQUIw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ac1VRxwwGiGIPKsbf5gw/2f+HO9BRp/uMq3z06khpoPH2k6cakfOEqEvv/17Q5cvMKGGTZ0Jym9sqKZf1KzpEOztTcUczAphLcz+rAqcyW4gljwKbIHR0OGKVoLrUbMyb2tlMVMqH2JM+MNvTbphP1Gy5VR0523V0eFYVICz6PI= X-YMail-OSG: L_vmb.8VM1muO5a3fySaEyUK3n_C29_5N11zKP_PmQn.zMS 6igZieAr9D3on2AKvs5ijdXEocgTSLkRucmTGoZZcqK8Pq2QGiXpw.Upzo4f gxvIusu.OFi2UvbEfbp0woC5UeVsO9B5Bem6.is4x4WQ4VCpn8LRE9BXaoxU MscYcJbid3guUskiHAupL28U15OhYOhNqJr.eH1Uzb.eu7wBHDXPgDFREaKx ycwj0bBYqJJnEWV5nZwm0kVXsTBt9rRUyb9sBNuJnU7Nz4Hjrc9u0lMbAEvt OV69u_DX.MlbYoAGQYpNgyIDfrPl385tLi4zIPhnF6jdC_TdkjU4d8ThIfKf TF_iZkVZKMFSVqS4MgGYi8ApUvMFkfdXA8bzj6otaNsMIqSJoA9dzzW1qlrS 2AVi192UmKdjRXZXPD9385GsL2.ERPT4LDwn9XCjTIWlHckXXClSoRL_lRaH OYbfejntnxX0AdoTSZs41Ecv6ADyjESL5Tczvg5cvqGXUne.JvkJbVHe8nKP ZoTwOP7WfoJ8aWvytXPIq8x0dzlgkFKsqqnfCjfDLZA7iA8o45G0h2f4z7r7 cQC59Hhw7tZl62tOYbL09STvcZ0VXl9UTs013X.dVLoJGV2puGEgqAVbxf7v CX0m34OTAIRfMPq74yJVAUlzirpbryQOzR0kcp5EvgKkqT5jJMT8i262kPMP aQwPaoVzhk8ffaWenfEaW22waLq5wBirMs8.XTKbLNIVacnXpOsEhHdUqRZ. tS1QMmg_yskcVFQ-- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Thu, 13 Mar 2014 06:27:56 PDT X-Rocket-MIMEInfo: 002.001, RGFuLAoKQXMgc29tZW9uZSB3aG8gd291bGQgdXNlIHRoZSBtZXRyaWNzIHByb2R1Y2VkIGJ5IG1lYXN1cmVtZW50IGRldmljZXMsIGl0IGlzIG9mIGdyZWF0IGludGVyZXN0IHRvIGtub3cgdGhlIGtpbmQgb2YgaW50ZXJmYWNlIHlvdSBhcmUgYW5hbHl6aW5nLiDCoCBGb3IgZXhhbXBsZSwgb2YgZG9pbmcgZGlhZ25vc3RpY3MgYW5kIHRoZSBpbnRlcmZhY2UgaXMgd2lyZWxlc3MsIG9uZSB3b3VsZCBleHBlY3QgbW9yZSBwYWNrZXQgbG9zcyBhbmQgcG90ZW50aWFsbHkgbGVzcyBzcGVlZCAoYXMgYSBnZW5lcmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> Message-ID: <1394717276.53021.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Thu, 13 Mar 2014 06:27:56 -0700 (PDT) From: Nalini Elkins To: "Romascanu, Dan \(Dan\)" , "STARK, BARBARA H" , Juergen Schoenwaelder , "trevor.burbridge@bt.com" In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-2073969600-1394717276=:53021" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GQgGlc2ENCJ8NGKHDPFDmfcgeso Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:28:06 -0000 --36908767-2073969600-1394717276=:53021 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dan,=0A=0AAs someone who would use the metrics produced by measurement devi= ces, it is of great interest to know the kind of interface you are analyzin= g. =A0 For example, of doing diagnostics and the interface is wireless, one= would expect more packet loss and potentially less speed (as a general rul= e, of course). =A0 Is this what you were getting at?=0A=0ABTW, passive meas= urements such as WireShark packet traces already have an indication of the = layer 2 interface, so I know what I am getting.=0A=0AAs another question, d= o we want to consider the topic of Multiple Provisioning Domains (https://d= atatracker.ietf.org/meeting/89/agenda/mif/)? =A0If I am understanding corre= ctly, this would allow a device to communicate over multiple interfaces. = =A0 Please let me know if I have misunderstood.=0A=A0=0AThanks,=0A=0ANalini= Elkins=0AInside Products, Inc.=0A(831) 659-8360=0Awww.insidethestack.com= =0A=0A=0A=0A________________________________=0A From: "Romascanu, Dan (Dan)= " =0ATo: "STARK, BARBARA H" ; Juergen S= choenwaelder ; "trevor.burbridge@bt.c= om" =0ACc: "marcelo@it.uc3m.es" ; "philip.eardley@bt.com" ; "lmap@ietf.org" =0ASent: Thursday, March 13, 2014 4:21 AM=0ASubject: Re: [lmap] = Information Model - Interface classification=0A =0A=0AHi,=0A=0AI am wonderi= ng what is the practical purpose or benefit of this classification for LMAP= . Does it change any bits on wire, protocol fields, location or organizatio= n of IANA registry? =0A=0ACan somebody explain? =0A=0AThanks and Regards,= =0A=0ADan=0A=0A=0A> -----Original Message-----=0A> From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of STARK, BARBARA H=0A> Sent: Thursday, March 1= 3, 2014 1:17 PM=0A> To: Juergen Schoenwaelder; trevor.burbridge@bt.com=0A> = Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org=0A> Subject: R= e: [lmap] Information Model - Interface classification=0A> =0A> > > We disc= ussed at IETF 89 the possibility of classifying interfaces=0A> > > and bein= g=0A> > able to use such classes in the Task or Channel configuration. For= =0A> > example, instead of having to specify ppp0 we might be able to say "= active=0A> WAN".=0A> > Other classes might exist for wireless, Wi-Fi, GPRS,= LAN, DSL etc.=0A> > >=0A> > > While this seems sensible, does anyone know = of existing interface=0A> > ontologies that are used elsewhere in the IETF = or wider industry that=0A> > we could learn from or reference?=0A> > >=0A> = >=0A> > IANA has an interface type registry [1]. Of course, these interface= =0A> > types are technology specific. Things like "active WAN" are usage=0A= > > specific classifications and the question is whether devices can be=0A>= > trusted to determine them correctly.=0A> >=0A> > /js=0A> >=0A> > [1] htt= p://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib=0A> =0A> Every t= ime I've participated in a discussion about "standard ways of=0A> expressin= g interfaces" (many instances of such discussions, in various=0A> groups), = we've always looked at this IANA registry and determined that it's=0A> usel= ess for this purpose. In every case, the people ended up either (1)=0A> def= ining their own enumerated list or (2) don't standardize and just accept=0A= > whatever names the underlying OS applies to the interface (i.e., no=0A> c= lassifying).=0A> =0A> When the devices are largely homogeneous or of a limi= ted set of different=0A> devices, using the OS name is workable.=0A> =0A> T= he reason the IANA list has been found useless for these purposes in the=0A= > past is because the interfaces in this registry are at all layers and som= e are=0A> not sufficiently specific (e.g., ieee80211 is used for all varian= ts -- a, b, g, n, ac;=0A> and a device with multiple radios, for example op= erating at 2.4 and 5 GHz=0A> would get the same classification). The fact t= hat they are at all layers presents=0A> ambiguity if an interface is specif= ic that has multiple IP interfaces riding over=0A> it. There is no ability = in it to distinguish different IP interfaces.=0A> =0A> For example, a "telc= o broadband" "residential gateway" can have (1) a=0A> management IP interfa= ce, (2) a default route "Internet service" IP interface,=0A> (3) an IPTV IP= interface, and (4) a VoIP IP interface. All of these may go over a=0A> sin= gle DSL, PON, or Ethernet (PHY) interface. They may be done using=0A> separ= ate ATM interfaces (not likely anymore, but done at one time),=0A> separate= PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer),=0A> separ= ate IP "default router" routes, or separate tunnels over a single IP=0A> ro= uted interface. And that's just the WAN. On the LAN, we have RGs with=0A> m= ultiple Wi-Fi radios operating at different frequencies and being used for= =0A> different purposes. So asking such a device to test over its "Wi-Fi" i= nterface is=0A> ambiguous. "LAN" is even more ambiguous.=0A> =0A> If the gr= oup would like, I can put together and provide you with information=0A> on = how various groups have tried to solve this sort of thing, based on publicl= y=0A> available docs. Maybe this would be useful insight.=0A> Barbara=0A> = =0A> _______________________________________________=0A> lmap mailing list= =0A> lmap@ietf.org=0A> https://www.ietf.org/mailman/listinfo/lmap=0A=0A____= ___________________________________________=0Almap mailing list=0Almap@ietf= .org=0Ahttps://www.ietf.org/mailman/listinfo/lmap --36908767-2073969600-1394717276=:53021 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
<= br>
As someone who would use the metrics produced by measure= ment devices, it is of great interest to know the kind of interface you are= analyzing.   For example, of doing diagnostics and the interface is w= ireless, one would expect more packet loss and potentially less speed (as a= general rule, of course).   Is this what you were getting at?<= /div>

BTW, passive measurements such as WireShark p= acket traces already have an indication of the layer 2 interface, so I know= what I am getting.

As another question, do we want to consider th= e topic of Multiple Provisioning Domains (https://datatracker.ietf.org/meeting/89/agenda/mif/)?  I= f I am understanding correctly, this would allow a device to communicate ov= er multiple interfaces.   Please let me know if I have misunderstood.
 
Thanks,

Nalini= Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.co= m

From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "STARK, BARBARA H" <bs7652@att.co= m>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; "trevor.burbri= dge@bt.com" <trevor.burbridge@bt.com>
Cc: "marcelo@it.uc3m.es" <marcelo@it.uc3m.es>; = "philip.eardley@bt.com" <philip.eardley@bt.com>; "lmap@ietf.org" <= lmap@ietf.org>
Sent: Thursday, March 13, 2014 4:21 AM
Subject: Re: [lmap] Information Model - Interface classificat= ion

=0AHi,

I a= m wondering what is the practical purpose or benefit of this classification= for LMAP. Does it change any bits on wire, protocol fields, location or or= ganization of IANA registry?

Can somebody explain?

Thanks a= nd Regards,

Dan


> -----Original Message-----
> F= rom: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BAR= BARA H
> Sent: Thursday, March 13, 2014 1:17 PM
> To: Juergen S= choenwaelder; trevor.burbridge@bt.com
> Cc: marcelo@i= t.uc3m.es; philip.eardley@bt.com; lmap@ietf.org
> Subject: Re: [lmap] Information Model - Interface classification
>
> &= gt; > We discussed at IETF 89 the possibility of classifying interfaces<= br>> > > and being
> > able to use such classes in the Ta= sk or Channel configuration. For
> > example, instead of having to= specify ppp0 we might be able to say "active
> WAN".
> > Ot= her classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc.
> &g= t; >
> > > While this seems sensible, does anyone know of ex= isting interface
> > ontologies that are used elsewhere in the IET= F or wider industry that
> > we could learn from or reference?
= > > >
> >
> > IANA has an interface type registr= y [1]. Of course, these interface
> > types are technology specifi= c. Things like "active WAN" are usage
> > specific classifications= and the question is whether devices can be
> > trusted to determine them correctly.
> >
> > /js
> >
&g= t; > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib>
> Every time I've participated in a discussion about "standar= d ways of
> expressing interfaces" (many instances of such discussion= s, in various
> groups), we've always looked at this IANA registry an= d determined that it's
> useless for this purpose. In every case, the= people ended up either (1)
> defining their own enumerated list or (= 2) don't standardize and just accept
> whatever names the underlying = OS applies to the interface (i.e., no
> classifying).
>
>= ; When the devices are largely homogeneous or of a limited set of different=
> devices, using the OS name is workable.
>
> The reaso= n the IANA list has been found useless for these purposes in the
> pa= st is because the interfaces in this registry are at all layers and some are
> not sufficiently specific (e.g., ieee80211 is used for al= l variants -- a, b, g, n, ac;
> and a device with multiple radios, fo= r example operating at 2.4 and 5 GHz
> would get the same classificat= ion). The fact that they are at all layers presents
> ambiguity if an= interface is specific that has multiple IP interfaces riding over
> = it. There is no ability in it to distinguish different IP interfaces.
&g= t;
> For example, a "telco broadband" "residential gateway" can have= (1) a
> management IP interface, (2) a default route "Internet servi= ce" IP interface,
> (3) an IPTV IP interface, and (4) a VoIP IP inter= face. All of these may go over a
> single DSL, PON, or Ethernet (PHY)= interface. They may be done using
> separate ATM interfaces (not lik= ely anymore, but done at one time),
> separate PPPoE interfaces, sepa= rate VLAN IDs (at the Ethernet MAC layer),
> separate IP "default router" routes, or separate tunnels over a single IP
> rout= ed interface. And that's just the WAN. On the LAN, we have RGs with
>= multiple Wi-Fi radios operating at different frequencies and being used fo= r
> different purposes. So asking such a device to test over its "Wi-= Fi" interface is
> ambiguous. "LAN" is even more ambiguous.
> <= br>> If the group would like, I can put together and provide you with in= formation
> on how various groups have tried to solve this sort of th= ing, based on publicly
> available docs. Maybe this would be useful i= nsight.
> Barbara
>
> __________________________________= _____________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap

__= _____________________________________________
lmap mailing list
lmap@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/lmap


--36908767-2073969600-1394717276=:53021-- From nobody Thu Mar 13 06:29:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0951A096A for ; Thu, 13 Mar 2014 06:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQvFYg4Sps11 for ; Thu, 13 Mar 2014 06:28:57 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id B86371A08BB for ; Thu, 13 Mar 2014 06:28:57 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-red.research.att.com (Postfix) with ESMTP id 70319554603; Thu, 13 Mar 2014 09:33:45 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-green.research.att.com (Postfix) with ESMTP id 5DDDBE2357; Thu, 13 Mar 2014 09:27:38 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 13 Mar 2014 09:28:50 -0400 From: "MORTON, ALFRED C (AL)" To: "trevor.burbridge@bt.com" , "dromasca@avaya.com" , "STARK, BARBARA H" , "j.schoenwaelder@jacobs-university.de" Date: Thu, 13 Mar 2014 09:28:49 -0400 Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8///8oyAgAAcDgD//+7PcP//26XA//+WXvA= Message-ID: <2845723087023D4CB5114223779FA9C80178CEF622@njfpsrvexg8.research.att.com> References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: 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: http://mailarchive.ietf.org/arch/msg/lmap/hxc94C0vpHYO32oZClq1TsZc5M8 Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 13:28:59 -0000 Dan, I can imagine cases where the interface technology used might influence the results analysis or the test stream design. Some tech. are "always-on", others assign resources when traffic requires them. In some cases, one type of access technology will be hidden behind others, or the technology may not be important at all. But I support sorting this out to the extent that we can. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > trevor.burbridge@bt.com > Sent: Thursday, March 13, 2014 7:29 AM > To: dromasca@avaya.com; STARK, BARBARA H; j.schoenwaelder@jacobs- > university.de > Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] Information Model - Interface classification >=20 > Yes. The Information Model allows the specification of an Interface as > either a Task or Channel parameter. At the moment this is a string (no > suggested change) and expresses a device interface (e.g. eth1, ppp0 etc.)= . > While the structure of the Information model does not need to change we d= o > need to say what data can be present in those strings. E.g. if a > Controller says "Active WAN" as an alias then the MA needs to know what > the Controller means by this. This does need to be standardised (if we > allow such aliases) or referenced to existing definitions. >=20 > Trevor. >=20 > >-----Original Message----- > >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > >Sent: 13 March 2014 11:21 > >To: STARK, BARBARA H; Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R > >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; lmap@ietf.org > >Subject: Re: [lmap] Information Model - Interface classification > > > >Hi, > > > >I am wondering what is the practical purpose or benefit of this > classification for > >LMAP. Does it change any bits on wire, protocol fields, location or > organization > >of IANA registry? > > > >Can somebody explain? > > > >Thanks and Regards, > > > >Dan > > > > > >> -----Original Message----- > >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA = H > >> Sent: Thursday, March 13, 2014 1:17 PM > >> To: Juergen Schoenwaelder; trevor.burbridge@bt.com > >> Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org > >> Subject: Re: [lmap] Information Model - Interface classification > >> > >> > > We discussed at IETF 89 the possibility of classifying interfaces > >> > > and being > >> > able to use such classes in the Task or Channel configuration. For > >> > example, instead of having to specify ppp0 we might be able to say > "active > >> WAN". > >> > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > >> > > > >> > > While this seems sensible, does anyone know of existing interface > >> > ontologies that are used elsewhere in the IETF or wider industry tha= t > >> > we could learn from or reference? > >> > > > >> > > >> > IANA has an interface type registry [1]. Of course, these interface > >> > types are technology specific. Things like "active WAN" are usage > >> > specific classifications and the question is whether devices can be > >> > trusted to determine them correctly. > >> > > >> > /js > >> > > >> > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib > >> > >> Every time I've participated in a discussion about "standard ways of > >> expressing interfaces" (many instances of such discussions, in various > >> groups), we've always looked at this IANA registry and determined that > it's > >> useless for this purpose. In every case, the people ended up either (1= ) > >> defining their own enumerated list or (2) don't standardize and just > accept > >> whatever names the underlying OS applies to the interface (i.e., no > >> classifying). > >> > >> When the devices are largely homogeneous or of a limited set of > different > >> devices, using the OS name is workable. > >> > >> The reason the IANA list has been found useless for these purposes in > the > >> past is because the interfaces in this registry are at all layers and > some are > >> not sufficiently specific (e.g., ieee80211 is used for all variants -- > a, b, g, n, ac; > >> and a device with multiple radios, for example operating at 2.4 and 5 > GHz > >> would get the same classification). The fact that they are at all > layers presents > >> ambiguity if an interface is specific that has multiple IP interfaces > riding over > >> it. There is no ability in it to distinguish different IP interfaces. > >> > >> For example, a "telco broadband" "residential gateway" can have (1) a > >> management IP interface, (2) a default route "Internet service" IP > interface, > >> (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these ma= y > go over a > >> single DSL, PON, or Ethernet (PHY) interface. They may be done using > >> separate ATM interfaces (not likely anymore, but done at one time), > >> separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC > layer), > >> separate IP "default router" routes, or separate tunnels over a single > IP > >> routed interface. And that's just the WAN. On the LAN, we have RGs wit= h > >> multiple Wi-Fi radios operating at different frequencies and being use= d > for > >> different purposes. So asking such a device to test over its "Wi-Fi" > interface is > >> ambiguous. "LAN" is even more ambiguous. > >> > >> If the group would like, I can put together and provide you with > information > >> on how various groups have tried to solve this sort of thing, based on > publicly > >> available docs. Maybe this would be useful insight. > >> Barbara > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 13 06:45:46 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BBB1A096A for ; Thu, 13 Mar 2014 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.547] 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 NeHfyLQnaAuQ for ; Thu, 13 Mar 2014 06:45:40 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 829D71A07CB for ; Thu, 13 Mar 2014 06:45:40 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 80C9CA02A1; Thu, 13 Mar 2014 09:45:33 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 3B76CA0296; Thu, 13 Mar 2014 09:45:33 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 09:45:33 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , "trevor.burbridge@bt.com" , "dromasca@avaya.com" , "STARK, BARBARA H" , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8wAIy8mAAAXR3LD//+6dAIAAAk6AgAAhXICAAEF3EA== Date: Thu, 13 Mar 2014 13:45:32 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B79C3A@SPQCMBX02.exfo.com> References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> <2845723087023D4CB5114223779FA9C80178CEF622@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178CEF622@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20562.006 X-TM-AS-Result: No--54.996-5.0-31-10 X-imss-scan-details: No--54.996-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20562.006 X-TMASE-Result: 10--54.996300-5.000000 X-TMASE-MatchedRID: HLMPCFyIyBOYAkXyry1XGhNEPNwNrw/r7QhHJRtVRQEP5UNwUjScFBTB iK+Vz/yCPavUKmAA72dU+6S8khnj9AWInrOFRfQxr51gSC67hpXwZGE/+dMc1jC5VM7Xtwdbp7u eaEkDqTOAT8geMwPsRMBHQDRe/m5h8oWuLhK0Tf2PQVakDkJU+eJc6hKWj0C1FJViChKBgZnOEM terKmLMcKlgAXB0xtA3c3CRAd2bOGn9EJj6muJHmMGiV639iF0IaLR+2xKRDJZnNfVLNptssZ1F 88rHoscyif967SctZnDCwrx7OfXze+c5IL6OTgObvssW25GCBbG8NKjRwUFvPHSsb509cZ3QQ/s 9vEJJnfAywYqtqXVkTbZ8yMcMnNiVDouK+mQGajmAId+2bAQwoab/1O/b86B+Cckfm+bb6BCt0g OISD0KkfMDa5uzxW0tzAD5P0OduvvkBiM1eNiXv3NPiyUzKzdYY0tNGdvli2XvL6Kb5YL4dEw+l HrZKHlCpHyL/bz6uReheh0dgb9ei4sHyQXWjZfwR3oBUcW2mMpWss5kPUFdLNC+L5uJOha4P2k6 c8cDOEGFsX+553eBWc9i0P1EjbOHp1tCNbIhnizLD5kmcW6ZPDmLV4R6UXm4hU+7OY4zgyGXWNB qn1KYiSyIZBGqrVYZlT8zFTuwFpHDA56FtY2CwhWgIsZuXlPkZs6eeBnIM1GMe+tDjQ3FmMBNE0 EwOtKj1mbw6/tKms/Ic8ea6pSaPWUZFWpEkltngIgpj8eDcDInWAWA4yE6bazRqvlkBL0AYt5Ki TiutkLbigRnpKlKT4yqD4LKu3A Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/psYVnB7Y7tRCwo3RJmw4VTv99g4 Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 13:45:42 -0000 I agree that striping tasks will be very challenging and have advocated not= to go this route. The tasks usually will have information about the interf= ace they ran on e.g. DSL, WiFi, and will have the that information on a per= task basis that will be part of the generated report. The collision problem is another issue. I thought there was agreement for a= n MA to execute tasks sequentially and there should only be a single active= task or task list. That would ensure that there are no collisions. There c= ould be many task lists stored in the MA but only one would be active at an= y one time. This is all under the control of one MC. //Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Thursday, March 13, 2014 9:29 AM To: trevor.burbridge@bt.com; dromasca@avaya.com; STARK, BARBARA H; j.schoen= waelder@jacobs-university.de Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model - Interface classification Dan, I can imagine cases where the interface technology used might influence the results analysis or the test stream design. Some tech. are "always-on", others assign resources when traffic requires them. In some cases, one type of access technology will be hidden behind others, or the technology may not be important at all. But I support sorting this out to the extent that we can. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of > trevor.burbridge@bt.com > Sent: Thursday, March 13, 2014 7:29 AM > To: dromasca@avaya.com; STARK, BARBARA H; j.schoenwaelder@jacobs- > university.de > Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] Information Model - Interface classification >=20 > Yes. The Information Model allows the specification of an Interface as > either a Task or Channel parameter. At the moment this is a string (no > suggested change) and expresses a device interface (e.g. eth1, ppp0 etc.)= . > While the structure of the Information model does not need to change we d= o > need to say what data can be present in those strings. E.g. if a > Controller says "Active WAN" as an alias then the MA needs to know what > the Controller means by this. This does need to be standardised (if we > allow such aliases) or referenced to existing definitions. >=20 > Trevor. >=20 > >-----Original Message----- > >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan > (Dan) > >Sent: 13 March 2014 11:21 > >To: STARK, BARBARA H; Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R > >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; lmap@ietf.org > >Subject: Re: [lmap] Information Model - Interface classification > > > >Hi, > > > >I am wondering what is the practical purpose or benefit of this > classification for > >LMAP. Does it change any bits on wire, protocol fields, location or > organization > >of IANA registry? > > > >Can somebody explain? > > > >Thanks and Regards, > > > >Dan > > > > > >> -----Original Message----- > >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA = H > >> Sent: Thursday, March 13, 2014 1:17 PM > >> To: Juergen Schoenwaelder; trevor.burbridge@bt.com > >> Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org > >> Subject: Re: [lmap] Information Model - Interface classification > >> > >> > > We discussed at IETF 89 the possibility of classifying interfaces > >> > > and being > >> > able to use such classes in the Task or Channel configuration. For > >> > example, instead of having to specify ppp0 we might be able to say > "active > >> WAN". > >> > Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc. > >> > > > >> > > While this seems sensible, does anyone know of existing interface > >> > ontologies that are used elsewhere in the IETF or wider industry tha= t > >> > we could learn from or reference? > >> > > > >> > > >> > IANA has an interface type registry [1]. Of course, these interface > >> > types are technology specific. Things like "active WAN" are usage > >> > specific classifications and the question is whether devices can be > >> > trusted to determine them correctly. > >> > > >> > /js > >> > > >> > [1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib > >> > >> Every time I've participated in a discussion about "standard ways of > >> expressing interfaces" (many instances of such discussions, in various > >> groups), we've always looked at this IANA registry and determined that > it's > >> useless for this purpose. In every case, the people ended up either (1= ) > >> defining their own enumerated list or (2) don't standardize and just > accept > >> whatever names the underlying OS applies to the interface (i.e., no > >> classifying). > >> > >> When the devices are largely homogeneous or of a limited set of > different > >> devices, using the OS name is workable. > >> > >> The reason the IANA list has been found useless for these purposes in > the > >> past is because the interfaces in this registry are at all layers and > some are > >> not sufficiently specific (e.g., ieee80211 is used for all variants -- > a, b, g, n, ac; > >> and a device with multiple radios, for example operating at 2.4 and 5 > GHz > >> would get the same classification). The fact that they are at all > layers presents > >> ambiguity if an interface is specific that has multiple IP interfaces > riding over > >> it. There is no ability in it to distinguish different IP interfaces. > >> > >> For example, a "telco broadband" "residential gateway" can have (1) a > >> management IP interface, (2) a default route "Internet service" IP > interface, > >> (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these ma= y > go over a > >> single DSL, PON, or Ethernet (PHY) interface. They may be done using > >> separate ATM interfaces (not likely anymore, but done at one time), > >> separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC > layer), > >> separate IP "default router" routes, or separate tunnels over a single > IP > >> routed interface. And that's just the WAN. On the LAN, we have RGs wit= h > >> multiple Wi-Fi radios operating at different frequencies and being use= d > for > >> different purposes. So asking such a device to test over its "Wi-Fi" > interface is > >> ambiguous. "LAN" is even more ambiguous. > >> > >> If the group would like, I can put together and provide you with > information > >> on how various groups have tried to solve this sort of thing, based on > publicly > >> available docs. Maybe this would be useful insight. > >> Barbara > >> > >> _______________________________________________ > >> 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 13 06:52:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488371A07CB for ; Thu, 13 Mar 2014 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 LtkRPKrsrceu for ; Thu, 13 Mar 2014 06:52:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id EE4701A082B for ; Thu, 13 Mar 2014 06:52:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C92EF10FB; Thu, 13 Mar 2014 14:52:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1u1ToQ7ngGGM; Thu, 13 Mar 2014 14:52:03 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 13 Mar 2014 14:52:03 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 179B72002F; Thu, 13 Mar 2014 14:52:03 +0100 (CET) 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 RKb2nSB8rU1T; Thu, 13 Mar 2014 14:52:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4126B2002C; Thu, 13 Mar 2014 14:52:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DE5CB2BC581D; Thu, 13 Mar 2014 14:51:58 +0100 (CET) Date: Thu, 13 Mar 2014 14:51:58 +0100 From: Juergen Schoenwaelder To: Nalini Elkins Message-ID: <20140313135156.GA86963@elstar.local> Mail-Followup-To: Nalini Elkins , "Romascanu, Dan (Dan)" , "STARK, BARBARA H" , "trevor.burbridge@bt.com" , "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> <1394717276.53021.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1394717276.53021.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/asosLCl92xg9LrusMiG2DRgm78w Cc: "lmap@ietf.org" , "trevor.burbridge@bt.com" , "Romascanu, Dan \(Dan\)" , "marcelo@it.uc3m.es" , "STARK, BARBARA H" , "philip.eardley@bt.com" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 13:52:15 -0000 On Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wrote: > > BTW, passive measurements such as WireShark packet traces already > have an indication of the layer 2 interface, so I know what I am > getting. Ehem, do not confuse the PCAP link-type with the technology that was used to ship the packet. They can be different. The PCAP link-type merely indicates the format the pcap trace is encoded with. It is easy to draw wrong conclusions from such assumptions. And even if the link-type correctly indicates a wired ethernet interface, the wire might simply end at an AP running a P2P link and you still have a wireless link involved in your measurement. Similarly, if a box takes care to label one Ethernet port as WAN port and the others as LAN ports and the OS carefully renames the OS interfaces wan and lan0, lan1, ..., there is no guarantee that the user did plug the cables correctly. Some boxes make the WAN port special by associating statically say a TR69 daemon with it so that there is an incentive to plug things right. But then the customer might have two home routers connected in series and what have you. /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 Mar 13 06:58:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27621A099D for ; Thu, 13 Mar 2014 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 pl_0IRQ86SJu for ; Thu, 13 Mar 2014 06:58:31 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27B1A096B for ; Thu, 13 Mar 2014 06:58:31 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8EAA8A02A3; Thu, 13 Mar 2014 09:58:24 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 4F1DDA02A0; Thu, 13 Mar 2014 09:58:24 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 09:58:24 -0400 From: Sharam Hakimi To: "trevor.burbridge@bt.com" Thread-Topic: [lmap] Information Model - Reporting Task collisions/interference Thread-Index: AQHPPqAyNb4PBnNby02nyeRd+Qdq9prfCrkQ Date: Thu, 13 Mar 2014 13:58:23 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B79C6E@SPQCMBX02.exfo.com> References: <20140313093947.GC85809@elstar.local> In-Reply-To: <20140313093947.GC85809@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20562.006 X-TM-AS-Result: No--26.486-5.0-31-10 X-imss-scan-details: No--26.486-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20562.006 X-TMASE-Result: 10--26.486000-5.000000 X-TMASE-MatchedRID: vbSD0OnL8/IDJrf2+hNOhdjko+KiQPUGQa2sDHLkQ067+NPPxj+R6jC0 pJIQUiJOdxO+yO6iocH0mu+mzF2JeHPlJcQgMP5rzNY33yIEF4b+JXhT18JvHSFH+Ny4EeQ+8Lg MA1SHJlGqaCNIMhjCUOU9Y5l2egV8uPsQw1lljokTRDzcDa8P62XffBVVuVHqnLVhzy0+RX2ooS DAIqqmjrKXfByFHeq3nafnxh7jZQDB6kugcU0FsEZakoam9+aeIcCiCHZJTlceeT009zDA0lpgd 595zqcS0UcH7xzzjChIXZwuZeurHtl+dy3lQHNxiUPZPmKZOQnvkROLxAaM3O2u9WxDRZ0zz9kx +yfBvAx3pnrjW0U1eVJ0vltSRqqXDAixBlu3NnBCvapcIkxJX3LhUU/qa4OGydovWuL+KVfEfUj 0FaEmILfqHaErmu92fyYDewMOrQDkwjHXXC/4I5BlLa6MK1y4 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_2xSc2TSlwsdo9MI3DJxcMUx870 Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Reporting Task collisions/interference 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, 13 Mar 2014 13:58:40 -0000 Sorry, I should have put the collision comment in this thread. The collision problem is another issue. I thought there was agreement for a= n MA to execute tasks sequentially and there should only be a single active= task or task list. That would ensure that there are no collisions. There c= ould be many task lists stored in the MA but only one would be active at an= y one time. This is all under the control of one MC. //SH -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Thursday, March 13, 2014 5:40 AM To: trevor.burbridge@bt.com Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Information Model - Reporting Task collisions/interfere= nce On Thu, Mar 13, 2014 at 09:36:00AM +0000, trevor.burbridge@bt.com wrote: > At IETF 89 we also discussed the requirement to be able to report if a Me= asurement Task may have conflicted with another Task. While this could be a= s simple as a Boolean in the Report for each Task, we could potentially con= sider something more complicated. Since a Boolean would not tell us which T= asks were operating concurrently and whether there might be cause for conce= rn (e.g. it could be a permanently running error reporting task or a passiv= e analysis task). >=20 > Therefore it seems likely that we want to discuss two approaches: > 1) listing the Tasks that overlapped with the execution of the reporting = Task. Simple conceptually and gives the most information to the person/syst= em analysing results. > 2) Attempt to classify Tasks by their potential conflict and report a con= flict level. E.g. colliding with a passive tasks might be conflict level 1,= but colliding with a TCP throughput test might be conflict level 5. Person= ally I'd be very much against such an approach as (a) I don't want to class= ify Tasks and (b) It's not really possible to give a general conflict ratin= g to a Task since it will affect different other Tasks to different levels. >=20 > So do people think 1) is the way forward? Shall we add "Conflicting Tasks= " (as a List of Task Names) to the Task header information in the Report? >=20 I agree that 2) is wishful thinking. I am also concerned to add noise to every report in cases where it is not needed. So this conflict report should be optional so that in cases where this is really not needed, you can save the noise in the report channel. /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 Thu Mar 13 06:58:52 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4721A098B for ; Thu, 13 Mar 2014 06:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 y2-DgqSd2Y_v for ; Thu, 13 Mar 2014 06:58:46 -0700 (PDT) Received: from nm11-vm8.access.bullet.mail.bf1.yahoo.com (nm11-vm8.access.bullet.mail.bf1.yahoo.com [216.109.114.231]) by ietfa.amsl.com (Postfix) with ESMTP id 09BA11A096B for ; Thu, 13 Mar 2014 06:58:45 -0700 (PDT) Received: from [66.196.81.162] by nm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Mar 2014 13:58:39 -0000 Received: from [66.196.81.148] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 13 Mar 2014 13:58:39 -0000 Received: from [127.0.0.1] by omp1024.access.mail.bf1.yahoo.com with NNFMP; 13 Mar 2014 13:58:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 423187.53466.bm@omp1024.access.mail.bf1.yahoo.com Received: (qmail 10187 invoked by uid 60001); 13 Mar 2014 13:58:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1394719118; bh=cByB8zuMZ0P9LQHZOzh+Ys8sS6Q43TgwVsXnA4yWF5s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iCJJHIos/ZyPzTkgIPqbYnQEcwb+Y1bafcc2xEsl8sq8XGemWAaQ7OJ5SX005w2R3jRHkv4P31hEPSd/hVE+i3aieLDOyeBZ4t5TnNexE1cktVh+FgFna/F8WwuU72A44TTH9uA4DxbfnrZlQpBa4blz9ElXiDHNnz0He3R1vVk= X-YMail-OSG: APXaV6oVM1nDBLiUaHCgZULwXXfNZe9JSnRqRA_jrYcZdS9 GbAAY3tvgsKMB1OlhfZg3YUEnnnWnP_b61tc..6LrkvAgDT9tiwrRhQZXGkC 2Hrn4sEleMJHcEAqeP8Z5yDkS_Vvjo1sG6lKRrM0YRxFhpp7Ctgh5HplAoOG 9ofROCbKwC0UzoIO0O4BpXMyXfoJC3nxn7QlsbB6qoqTHMC30mJOl3clzK3G DivyibbWVt.TbTVmTX.u_ydgNiPsYHRFsSujFlOFUKSKF6Dqtq_uwmlTHObB V8.ttl.PzBDdh_fCKWYRE0oDI8i9iMp6TszqXAggX5QdDzi7qi128tIbA9SC jtSzI8wVmq6wSHMNoVvKuQGmoXa6G1e4_XMRj8v4GTdLDkntdTvQ4ntygkXP Xd42aFujb9F1zDt3pQKYInXjljkeuBR7S.A0BQopTXuHupo3MEHIujZjlW9J xC9X1bO7aCZYdKcnEBO0V27cmoP6T_9sIKnv6fV3RhD_W2BmXvYghmzR2iAZ TTyzVMZBjuRaSvABVUiNHS8DFYVkRqbI3FYAHW9nxvQYBe5sA_.F8xlP4HQW W0wqqPg6vCaGqLQOcdKuZBq2Rd2PdRrhN7J7umgKKUgTKtY0RhQF4XdsN.XX FiAFyDSgOw0QrzpBPgWg0WaJ._spoSrQp7uumyTXnj.x1fja5thxFdJwLC4b euLrkr1O.zhHA53O7WzHahKg1hMKE0zIXckUUbyqYsJGmdeyUjpE- Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Thu, 13 Mar 2014 06:58:38 PDT X-Rocket-MIMEInfo: 002.001, R29vZCBwb2ludCEKwqAKVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uCgpJZiB3ZSBjYW4ga25vdyB0aGUgaW50ZXJmYWNlIHR5cGUsIGl0IGlzIHVzZWZ1bCwgdGhvdWdoLgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU.ClRvOiBOYWxpbmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.178.641 References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> <1394717276.53021.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <20140313135156.GA86963@elstar.local> Message-ID: <1394719118.2896.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Thu, 13 Mar 2014 06:58:38 -0700 (PDT) From: Nalini Elkins To: Juergen Schoenwaelder In-Reply-To: <20140313135156.GA86963@elstar.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-88260017-1394719118=:2896" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VOiT3IgXtLWRw-hvY4kCDBfQlNM Cc: "lmap@ietf.org" , "trevor.burbridge@bt.com" , "Romascanu, Dan \(Dan\)" , "marcelo@it.uc3m.es" , "STARK, BARBARA H" , "philip.eardley@bt.com" Subject: Re: [lmap] Information Model - Interface classification X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 13:58:50 -0000 --1619178251-88260017-1394719118=:2896 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good point!=0A=A0=0AThanks for the information.=0A=0AIf we can know the int= erface type, it is useful, though.=0A=0ANalini Elkins=0AInside Products, In= c.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A___________________= _____________=0A From: Juergen Schoenwaelder =0ATo: Nalini Elkins =0ACc: "Rom= ascanu, Dan (Dan)" ; "STARK, BARBARA H" ; "trevor.burbridge@bt.com" ; "marcelo@it.uc3m.es= " ; "philip.eardley@bt.com" ; "l= map@ietf.org" =0ASent: Thursday, March 13, 2014 6:51 AM=0AS= ubject: Re: [lmap] Information Model - Interface classification=0A =0A=0AOn= Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wrote:=0A> =0A> BTW, = passive measurements such as WireShark packet traces already=0A> have an in= dication of the layer 2 interface, so I know what I am=0A> getting.=0A=0AEh= em, do not confuse the PCAP link-type with the technology that was=0Aused t= o ship the packet. They can be different. The PCAP link-type=0Amerely indic= ates the format the pcap trace is encoded with. It is easy=0Ato draw wrong = conclusions from such assumptions. And even if the=0Alink-type correctly in= dicates a wired ethernet interface, the wire=0Amight simply end at an AP ru= nning a P2P link and you still have a=0Awireless link involved in your meas= urement.=0A=0ASimilarly, if a box takes care to label one Ethernet port as = WAN port=0Aand the others as LAN ports and the OS carefully renames the OS= =0Ainterfaces wan and lan0, lan1, ..., there is no guarantee that the=0Ause= r did plug the cables correctly. Some boxes make the WAN port=0Aspecial by = associating statically say a TR69 daemon with it so that=0Athere is an ince= ntive to plug things right. But then the customer=0Amight have two home rou= ters connected in series and what have you.=0A=0A/js=0A=0A-- =0AJuergen Sch= oenwaelder=A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH=0APhone: +49 = 421 200 3587=A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany=0AFax:=A0= +49 421 200 3103=A0 =A0 =A0 =A0 --1619178251-88260017-1394719118=:2896 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Good point!
 
Thanks for the information.
<= br>
If we can know the interface type, it is useful, though.

Nalini Elkins
Inside Products, Inc.
(831) 659-83= 60
www.insidethestack.com

From: Juergen Schoenwaelder <j.schoenwaelder@= jacobs-university.de>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "STARK, BARBARA H" <bs7652@att.com>; "tr= evor.burbridge@bt.com" <trevor.burbridge@bt.com>; "marcelo@it.uc3m.es= " <marcelo@it.uc3m.es>; "philip.eardley@bt.com" <philip.eardley@bt= .com>; "lmap@ietf.org" <lmap@ietf.org>
Sent: Thursday, March 13, 2014 6:51 AM
Subject: Re: [lmap] Information= Model - Interface classification

=0AOn Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wro= te:
>
> BTW, passive measurements such as WireShark packet tra= ces already
> have an indication of the layer 2 interface, so I know = what I am
> getting.

Ehem, do not confuse the PCAP link-type w= ith the technology that was
used to ship the packet. They can be differe= nt. The PCAP link-type
merely indicates the format the pcap trace is enc= oded with. It is easy
to draw wrong conclusions from such assumptions. A= nd even if the
link-type correctly indicates a wired ethernet interface,= the wire
might simply end at an AP running a P2P link and you still hav= e a
wireless link involved in your measurement.

Similarly, if a b= ox takes care to label one Ethernet port as WAN port
and the others as L= AN ports and the OS carefully renames the OS
interfaces wan and lan0, la= n1, ..., there is no guarantee that the
user did plug the cables correct= ly. Some boxes make the WAN port
special by associating statically say a TR69 da= emon with it so that
there is an incentive to plug things right. But the= n the customer
might have two home routers connected in series and what = have you.

/js

--
Juergen Schoenwaelder     = ;     Jacobs University Bremen gGmbH
Phone: +49 421 200 3587&= nbsp;       Campus Ring 1, 28759 Bremen, Germany
Fax:&nb= sp; +49 421 200 3103        <http://www.jacobs-uni= versity.de/>


--1619178251-88260017-1394719118=:2896-- From nobody Thu Mar 13 07:16:12 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DB61A096E for ; Thu, 13 Mar 2014 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 yRRpksCtEPUU for ; Thu, 13 Mar 2014 07:15:57 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 433A81A098A for ; Thu, 13 Mar 2014 07:15:55 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 894CBA0296; Thu, 13 Mar 2014 10:15:48 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 40E4FA0293; Thu, 13 Mar 2014 10:15:48 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 10:15:48 -0400 From: Sharam Hakimi To: Nalini Elkins , Juergen Schoenwaelder Thread-Topic: [lmap] Information Model - Interface classification Thread-Index: Ac8+nhdiycKNyYekREmINJyBU3xq8wAIy8mAAAXR3LD//+6dAIAAI2sAgAAGtwCAAAHdAIAAPs1g Date: Thu, 13 Mar 2014 14:15:47 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B79CE5@SPQCMBX02.exfo.com> References: <20140313093644.GB85809@elstar.local> <2D09D61DDFA73D4C884805CC7865E6113040AC08@GAALPA1MSGUSR9L.ITServices.sbc.com> <9904FB1B0159DA42B0B887B7FA8119CA2E457AB9@AZ-FFEXMB04.global.avaya.com> <1394717276.53021.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <20140313135156.GA86963@elstar.local> <1394719118.2896.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> In-Reply-To: <1394719118.2896.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: multipart/alternative; boundary="_000_89294A6F3C6C91459E52E4128C4B02B79CE5SPQCMBX02exfocom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20562.006 X-TM-AS-Result: No--24.211-5.0-31-10 X-imss-scan-details: No--24.211-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20562.006 X-TMASE-Result: 10--24.211400-5.000000 X-TMASE-MatchedRID: oCj5caaCQykTRq2fvEtvbUAoPtuOD8ba9CFlFEyD3YQ86FJGM55QNiR6 K0d8CivmqWWy+joNU7WY0QfgAkRqLeDBvYycsJwVox5cBdU3pAdBldmDYjwlprq5EV5W6UBD0u5 faGP8ztTUVzrVUIa+HUQ0ZbDoCgw3gwHdQ7Tdau0mT1pl/auP2wreImldQ5BD6Iw92uZxnCvg4a YMmmX0/uXqsEkKcqQklXvOstRbkytS3gJgpoiQvAPZZctd3P4BQKuv8uQBDjooG/4CHNlRAaGrR k5krkQ4px4hFA47W2GYNAnaGU05M+eYMko8W4p+71Wx2uUbPLdAkxQSMQ88CqlVRHRK9i1KjNLx rcxKViWMkVsdMJZ1Bj57Vewgel4zjRNPwOvIr3XDa1qWPNOExuBgp+G3IXxr8cWgFw6wp7M9n3n 8h2QE9MRDJocb7hJ+PC7j/mzpDFrd4xdn1XD3cwwfhKwa9GwDWq9ln3+CkiFnnK6mXN72mznuQW M5MjklgExzV+J9XRhRqc17zaHc5zWBtSWZ+bE6pJSLa4cXZX19e88fgoklswwv1ZvdCH+FmPMvF iO40LCPL1kerA0y5GI5lFIlyFoz0nbjHOkZyPm2FK5J1KhC+0opYlyHMD9xp5PFVaVNRTbJmMcL aJBXasV6a4pfRRDGFABeLgZr0ZEfE8yM4pjsD/7E6GNqs6ce94NPgD4m7QhFGCd0S0NCstLZwrD zQ0eTqZyWxPTaoNX+9DMIout2f1bSIq4U4uNUS4W/MRhJ1X4= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ou9DeukmeXO9w4zoqPZOJGELArc Cc: "lmap@ietf.org" , "trevor.burbridge@bt.com" , "Romascanu, Dan \(Dan\)" , "marcelo@it.uc3m.es" , "STARK, BARBARA H" , "philip.eardley@bt.com" Subject: Re: [lmap] Information Model - Interface classification 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, 13 Mar 2014 14:16:04 -0000 --_000_89294A6F3C6C91459E52E4128C4B02B79CE5SPQCMBX02exfocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One could easily extrapolate the interface used from the IP that was used t= o transfer data. It just takes a little more post processing. //SH From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins Sent: Thursday, March 13, 2014 9:59 AM To: Juergen Schoenwaelder Cc: lmap@ietf.org; trevor.burbridge@bt.com; Romascanu, Dan (Dan); marcelo@i= t.uc3m.es; STARK, BARBARA H; philip.eardley@bt.com Subject: Re: [lmap] Information Model - Interface classification Good point! Thanks for the information. If we can know the interface type, it is useful, though. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Juergen Schoenwaelder To: Nalini Elkins Cc: "Romascanu, Dan (Dan)" ; "STARK, BARBARA H" ; "trevor.burbridge@bt.com" ; "marcelo@it= .uc3m.es" ; "philip.eardley@bt.com" ; "lmap@ietf.org" Sent: Thursday, March 13, 2014 6:51 AM Subject: Re: [lmap] Information Model - Interface classification On Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wrote: > > BTW, passive measurements such as WireShark packet traces already > have an indication of the layer 2 interface, so I know what I am > getting. Ehem, do not confuse the PCAP link-type with the technology that was used to ship the packet. They can be different. The PCAP link-type merely indicates the format the pcap trace is encoded with. It is easy to draw wrong conclusions from such assumptions. And even if the link-type correctly indicates a wired ethernet interface, the wire might simply end at an AP running a P2P link and you still have a wireless link involved in your measurement. Similarly, if a box takes care to label one Ethernet port as WAN port and the others as LAN ports and the OS carefully renames the OS interfaces wan and lan0, lan1, ..., there is no guarantee that the user did plug the cables correctly. Some boxes make the WAN port special by associating statically say a TR69 daemon with it so that there is an incentive to plug things right. But then the customer might have two home routers connected in series and what have you. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --_000_89294A6F3C6C91459E52E4128C4B02B79CE5SPQCMBX02exfocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One could easily extrapolate the interface used from the IP = that was used to transfer data. It just takes a little more post processing= .

 

//SH

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Nalini Elkins
Sent: Thursday, March 13, 2014 9:59 AM
To: Juergen Schoenwaelder
Cc: lmap@ietf.org; trevor.burbridge@bt.com; Romascanu, Dan (Dan); ma= rcelo@it.uc3m.es; STARK, BARBARA H; philip.eardley@bt.com
Subject: Re: [lmap] Information Model - Interface classification

 

Good point!

 

Thanks for the information.

 

If we can know the interface type, it is useful, though.<= /o:p>

 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

 

From: Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; &qu= ot;STARK, BARBARA H" <bs7652@att.com>; "trevor.burbridge@bt= .com" <trevor.burbridge@bt.com>; "marcelo@it.uc3m.es" = <marcelo@it.uc3m.es>; "philip.eardley@bt.com" <philip.ea= rdley@bt.com>; "lmap@ietf.org" <lmap@ietf.org>
Sent: Thursday, March 13, 2014 6:51 AM
Subject: Re: [lmap] Information Model - Interface classification


On Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wrote:
>
> BTW, passive measurements such as WireShark packet traces already
> have an indication of the layer 2 interface, so I know what I am
> getting.

Ehem, do not confuse the PCAP link-type with the technology that was
used to ship the packet. They can be different. The PCAP link-type
merely indicates the format the pcap trace is encoded with. It is easy
to draw wrong conclusions from such assumptions. And even if the
link-type correctly indicates a wired ethernet interface, the wire
might simply end at an AP running a P2P link and you still have a
wireless link involved in your measurement.

Similarly, if a box takes care to label one Ethernet port as WAN port
and the others as LAN ports and the OS carefully renames the OS
interfaces wan and lan0, lan1, ..., there is no guarantee that the
user did plug the cables correctly. Some boxes make the WAN port
special by associating statically say a TR69 daemon with it so that
there is an incentive to plug things right. But then the customer
might have two home routers connected in series and what have you.

/js

--
Juergen Schoenwaelder          Jacobs University B= remen gGmbH
Phone: +49 421 200 3587        Campus Ring 1, 28759= Bremen, Germany
Fax:  +49 421 200 3103        <http://www.j= acobs-university.de/>

--_000_89294A6F3C6C91459E52E4128C4B02B79CE5SPQCMBX02exfocom_-- From nobody Thu Mar 13 07:39:25 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDD91A09D8 for ; Thu, 13 Mar 2014 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDF52diIw6Wu for ; Thu, 13 Mar 2014 07:39:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C81A09C9 for ; Thu, 13 Mar 2014 07:39:19 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 14:39:23 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.16]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 13 Mar 2014 14:38:38 +0000 From: To: Date: Thu, 13 Mar 2014 14:38:38 +0000 Thread-Topic: [lmap] Information Model - Reporting Task collisions/interference Thread-Index: AQHPPqAyNb4PBnNby02nyeRd+Qdq9prfCrkQgAALZaA= Message-ID: References: <20140313093947.GC85809@elstar.local> <89294A6F3C6C91459E52E4128C4B02B79C6E@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B79C6E@SPQCMBX02.exfo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/i4rr10SuEcsaXcGJmg7jle5yTwg Cc: marcelo@it.uc3m.es, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] Information Model - Reporting Task collisions/interference 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, 13 Mar 2014 14:39:23 -0000 We're talking about the framework decision here (rather than Information Mo= del), but no. The decision discussed was to allow Tasks to conflict/overlap= if they are scheduled as such. Within a single schedule they are non-overl= apping. Trevor. >-----Original Message----- >From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >Sent: 13 March 2014 13:58 >To: Burbridge,T,Trevor,TUB8 R >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Information Model - Reporting Task collisions/interfer= ence > >Sorry, I should have put the collision comment in this thread. > >The collision problem is another issue. I thought there was agreement for = an MA >to execute tasks sequentially and there should only be a single active tas= k or task >list. That would ensure that there are no collisions. There could be many = task lists >stored in the MA but only one would be active at any one time. This is all= under >the control of one MC. > >//SH > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >Schoenwaelder >Sent: Thursday, March 13, 2014 5:40 AM >To: trevor.burbridge@bt.com >Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org >Subject: Re: [lmap] Information Model - Reporting Task collisions/interfer= ence > >On Thu, Mar 13, 2014 at 09:36:00AM +0000, trevor.burbridge@bt.com wrote: >> At IETF 89 we also discussed the requirement to be able to report if a >Measurement Task may have conflicted with another Task. While this could b= e as >simple as a Boolean in the Report for each Task, we could potentially cons= ider >something more complicated. Since a Boolean would not tell us which Tasks = were >operating concurrently and whether there might be cause for concern (e.g. = it >could be a permanently running error reporting task or a passive analysis = task). >> >> Therefore it seems likely that we want to discuss two approaches: >> 1) listing the Tasks that overlapped with the execution of the reporting= Task. >Simple conceptually and gives the most information to the person/system >analysing results. >> 2) Attempt to classify Tasks by their potential conflict and report a co= nflict level. >E.g. colliding with a passive tasks might be conflict level 1, but collidi= ng with a >TCP throughput test might be conflict level 5. Personally I'd be very much= against >such an approach as (a) I don't want to classify Tasks and (b) It's not re= ally >possible to give a general conflict rating to a Task since it will affect = different >other Tasks to different levels. >> >> So do people think 1) is the way forward? Shall we add "Conflicting Task= s" (as a >List of Task Names) to the Task header information in the Report? >> > >I agree that 2) is wishful thinking. I am also concerned to add noise to e= very >report in cases where it is not needed. So this conflict report should be = optional >so that in cases where this is really not needed, you can save the noise i= n the >report channel. > >/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 Thu Mar 13 08:30:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3151A08ED for ; Thu, 13 Mar 2014 08:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsQlxY4Lhekx for ; Thu, 13 Mar 2014 08:30:09 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7451A09F0 for ; Thu, 13 Mar 2014 08:30:08 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 13 Mar 2014 15:28:37 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.168]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 13 Mar 2014 15:29:28 +0000 From: To: Date: Thu, 13 Mar 2014 15:29:27 +0000 Thread-Topic: Progress on Framework Thread-Index: Ac8+w09PTIYfj8AUQTCGd5DdMjlH6w== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F2099B2AEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2Ki465i5iHQPG1MS7_b4ANYnZj0 Subject: [lmap] Progress on Framework 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, 13 Mar 2014 15:30:14 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F2099B2AEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm trying to resolve the issues raised in WG Last call about the framework= http://tools.ietf.org/html/draft-ietf-lmap-framework-03 1. Especially if you weren't in London, please can you check the slides = to make sure you're happy with the proposed consensus on the various issues= . http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf (ignore sli= des 5, 6, 7 - see link below instead) 2. I prepared some slides about the MA vs MP terminology in action. Do t= hese examples help clarify things? They could be turned into some text for = the next version of the framework http://www.leone-project.eu/drupal/sites= /default/files/public_downloads/lmap-framework-examples-13march2014.pdf I plan to work on the framework i-d next week, so please let me know if you= have any comments. Background: A group of us met for a side meeting in London and (we think) r= eached consensus on all the open issues. I presented the proposals during t= he WG meeting in London. We had some good discussion, especially about the = terminology for Measurement Peer, which led to consensus round a slightly r= evised wording, and the suggestion that the i-d should include some explana= tory examples, to illustrate the MA vs MP terminology in action. Thanks! Best wishes phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F2099B2AEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m trying to resol= ve the issues raised in WG Last call about the framework http://tools.ietf.org/htm= l/draft-ietf-lmap-framework-03

&= nbsp;

1.=     Especially if you weren’t in London, please can you check = the slides to make sure you’re happy with the proposed consensus on t= he various issues. http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf=    (ignore slides 5, 6, 7 – see link below instead)

2.    <= /span>I prepared some slides about the MA vs MP terminology in action. Do = these examples help clarify things? They could be turned into some text for= the next version of the framework  http://www.leone-project.eu/drupal/sites/default/files/publi= c_downloads/lmap-framework-examples-13march2014.pdf <= /p>

 

I plan to work on th= e framework i-d next week, so please let me know if you have any comments. =

 

B= ackground: A group of us met for a side meeting in London and (we think) re= ached consensus on all the open issues. I presented the proposals during th= e WG meeting in London. We had some good discussion, especially about the t= erminology for Measurement Peer, which led to consensus round a slightly re= vised wording, and the suggestion that the i-d should include some explanat= ory examples, to illustrate the MA vs MP terminology in action.<= /span>

 

Thanks!<= /o:p>

Best wishes

ph= il

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F2099B2AEMV67UKRDdoma_-- From nobody Thu Mar 13 09:37:02 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6F1A0A16 for ; Thu, 13 Mar 2014 09:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.547] 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 TkZhtBaZhc2T for ; Thu, 13 Mar 2014 09:36:58 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 642361A09A7 for ; Thu, 13 Mar 2014 09:36:58 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85E17A028A; Thu, 13 Mar 2014 12:36:51 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 46244A027E; Thu, 13 Mar 2014 12:36:51 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Thu, 13 Mar 2014 12:36:50 -0400 From: Sharam Hakimi To: "trevor.burbridge@bt.com" Thread-Topic: [lmap] Information Model - Reporting Task collisions/interference Thread-Index: AQHPPqAyNb4PBnNby02nyeRd+Qdq9prfCrkQgAALZaCAAByaEA== Date: Thu, 13 Mar 2014 16:36:50 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B79E6E@SPQCMBX02.exfo.com> References: <20140313093947.GC85809@elstar.local> <89294A6F3C6C91459E52E4128C4B02B79C6E@SPQCMBX02.exfo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20564.000 X-TM-AS-Result: No--38.137-5.0-31-10 X-imss-scan-details: No--38.137-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20564.000 X-TMASE-Result: 10--38.137500-5.000000 X-TMASE-MatchedRID: rYpa/RC+czHWKlsMlVwfQ+J28KqpjndpK70vctTSAAeHwGEm+CpYGZdE DnskDq+W36i+diWYeePDvwUIQy7aDeS7PZsP9IZBa0ypt9SBZ6wZskwWqoib3ChRDl+D5lwG8Wg 4O0OhfZDwL8FsvUuUnGuWXNVvuqWrcqDNL2RTzARbd1zMnVGjF0GtrAxy5ENOu/jTz8Y/keowtK SSEFIiTncTvsjuoqHB9JrvpsxdiXhz5SXEIDD+a/s3IjAeeG139r9tEcSw8jfpVtVjg/LrZROuo XXlTr984xpUrXJtjyfcw7e4AO62udVIlpTwXF0CfKmN9+B2Aw9DGFvBeB2nXBxkWxg79K4IYCEn AolpChDnPEZEn2AuvrKIIInD68JGD0VXqQ1iI8dNVr4vdmCpzhWtwWPKSul25DJ1FS+XdBPRIkC LRkbt6nyvEloIIHkuHF/tgeV5mN3K7meRl+9tzYD9LizgRBhQ+ccIIOk4Y44z91mDYZLM5ZL73W 3BBZ7re0dHh3IIJ0OWJcbpNaIEAKvcAPrbUKHMngIgpj8eDcDInWAWA4yE6aKD0aiE4+c4q7rFU cuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4nrvQHHnEmMDYPRic3Xa4w4jTHk Cc: "marcelo@it.uc3m.es" , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Information Model - Reporting Task collisions/interference 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, 13 Mar 2014 16:37:00 -0000 Option 2 is really not workable in my opinion not only one has know the con= flict level, but say running Two level 3 tasks would not have a problem if = they conflicted but running three level 3 will oversubscribe the network. T= he possibilities are numerous where the MA must have extensive knowledge of= not only the conflict level but the interface that is using to effectively= identify a conflict. If conflicts are generated where it does not matter t= hen to much unnecessary conflict alarms are raised cluttering the reports a= s it was mentioned below. /Sharam=20 -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Thursday, March 13, 2014 10:39 AM To: Sharam Hakimi Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org Subject: RE: [lmap] Information Model - Reporting Task collisions/interfere= nce We're talking about the framework decision here (rather than Information Mo= del), but no. The decision discussed was to allow Tasks to conflict/overlap= if they are scheduled as such. Within a single schedule they are non-overl= apping. Trevor. >-----Original Message----- >From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] >Sent: 13 March 2014 13:58 >To: Burbridge,T,Trevor,TUB8 R >Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; lmap@ietf.org >Subject: RE: [lmap] Information Model - Reporting Task collisions/interfer= ence > >Sorry, I should have put the collision comment in this thread. > >The collision problem is another issue. I thought there was agreement for = an MA >to execute tasks sequentially and there should only be a single active tas= k or task >list. That would ensure that there are no collisions. There could be many = task lists >stored in the MA but only one would be active at any one time. This is all= under >the control of one MC. > >//SH > > > >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen >Schoenwaelder >Sent: Thursday, March 13, 2014 5:40 AM >To: trevor.burbridge@bt.com >Cc: marcelo@it.uc3m.es; philip.eardley@bt.com; lmap@ietf.org >Subject: Re: [lmap] Information Model - Reporting Task collisions/interfer= ence > >On Thu, Mar 13, 2014 at 09:36:00AM +0000, trevor.burbridge@bt.com wrote: >> At IETF 89 we also discussed the requirement to be able to report if a >Measurement Task may have conflicted with another Task. While this could b= e as >simple as a Boolean in the Report for each Task, we could potentially cons= ider >something more complicated. Since a Boolean would not tell us which Tasks = were >operating concurrently and whether there might be cause for concern (e.g. = it >could be a permanently running error reporting task or a passive analysis = task). >> >> Therefore it seems likely that we want to discuss two approaches: >> 1) listing the Tasks that overlapped with the execution of the reporting= Task. >Simple conceptually and gives the most information to the person/system >analysing results. >> 2) Attempt to classify Tasks by their potential conflict and report a co= nflict level. >E.g. colliding with a passive tasks might be conflict level 1, but collidi= ng with a >TCP throughput test might be conflict level 5. Personally I'd be very much= against >such an approach as (a) I don't want to classify Tasks and (b) It's not re= ally >possible to give a general conflict rating to a Task since it will affect = different >other Tasks to different levels. >> >> So do people think 1) is the way forward? Shall we add "Conflicting Task= s" (as a >List of Task Names) to the Task header information in the Report? >> > >I agree that 2) is wishful thinking. I am also concerned to add noise to e= very >report in cases where it is not needed. So this conflict report should be = optional >so that in cases where this is really not needed, you can save the noise i= n the >report channel. > >/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 Wed Mar 19 17:49:34 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634291A0835 for ; Wed, 19 Mar 2014 17:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0--9W3WDbxv for ; Wed, 19 Mar 2014 17:49:27 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 599E31A0841 for ; Wed, 19 Mar 2014 17:49:27 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so137378veb.13 for ; Wed, 19 Mar 2014 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=66Rhpo87F3wusykK6sQ12438Wtoqa4G42/0HB3cXNP4=; b=EUccwlWYlnr85/B357/2eGA/rDgFAuXFWRexJgyQlSf+sICrNQAboS0O4lN2D3/ujI V9nHcWuuv6uxR+3B9GJuZRhiPHXwxCTUjDkeZWrkfq5K6MbzAz3Ywu1M/CE8o1KkZARa VuEMW7g6XB/IoSLN399i2EayrZMJ5lxt9wORguL2qxE+1h5iCdYES7s0StiI57fOlULR QPI/zg3zlaNna+D4GpGYTMcEMK4DbHbGQcuMemsfFBvQTxPWuILJizOa/Aj833PE2kiS YHA1JDIf/GgIpFApSQb86yDC0Vox30btBcBBpm6Bb4qAqXaIaQSL6IVAPPL/Cw+OvZ3K ufaQ== MIME-Version: 1.0 X-Received: by 10.52.189.33 with SMTP id gf1mr16443204vdc.26.1395276558303; Wed, 19 Mar 2014 17:49:18 -0700 (PDT) Received: by 10.220.108.132 with HTTP; Wed, 19 Mar 2014 17:49:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Mar 2014 17:49:18 -0700 Message-ID: From: Greg Mirsky To: philip.eardley@bt.com Content-Type: multipart/alternative; boundary=001a1136b2629f0cf004f4ff2326 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/wWf2evcXmPVXCe_6S6e1wSKdbws Cc: "lmap@ietf.org" Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 00:49:31 -0000 --001a1136b2629f0cf004f4ff2326 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, I've got a question on: Basic distinction between MA and Measurement Peer - MA interacts with Controller and Collector - MP doesn't My question What would call a node that doesn't interact with Controller but does interact with Collector? Would characterize it as MA or MP? Or you believe that such scenario is not realistic or must not be allowed? If we consider, for example, OWAMP as in Example 1b but with minor modification. Fetch-Client (acts as Collector) may retrieve measurements from Server/Session-Receiver and not be co-located with Session-Sender (acts as MA). Would Session-Receiver be viewed as MA since Server is part of Controller or as MP? Regards, Greg On Thu, Mar 13, 2014 at 8:29 AM, wrote: > I'm trying to resolve the issues raised in WG Last call about the > framework http://tools.ietf.org/html/draft-ietf-lmap-framework-03 > > > > 1. Especially if you weren't in London, please can you check the > slides to make sure you're happy with the proposed consensus on the various > issues. http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf > (ignore slides 5, 6, 7 - see link below instead) > > 2. I prepared some slides about the MA vs MP terminology in action. Do > these examples help clarify things? They could be turned into some text for > the next version of the framework > http://www.leone-project.eu/drupal/sites/default/files/public_downloads/lmap-framework-examples-13march2014.pdf > > > > I plan to work on the framework i-d next week, so please let me know if > you have any comments. > > > > Background: A group of us met for a side meeting in London and (we think) > reached consensus on all the open issues. I presented the proposals during > the WG meeting in London. We had some good discussion, especially about the > terminology for Measurement Peer, which led to consensus round a slightly > revised wording, and the suggestion that the i-d should include some > explanatory examples, to illustrate the MA vs MP terminology in action. > > > > Thanks! > > Best wishes > > phil > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a1136b2629f0cf004f4ff2326 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phil,
I've got a question on:
Basic=09  distinction=09  between=09  MA=09  and=09  Measurement=09  Peer=09  
– MA=09  interacts=09  with=09  Controller=09  and=09  Collector=09  
– MP=09  doesn’t=09  =09
My question What would call a node that doesn't interact with Controll= er but does interact with Collector? Would characterize it as MA or MP? Or&= nbsp; you believe that such scenario is not realistic or must not be allowe= d?
If we consider, for example, OWAMP as in Example 1b but with minor modifica= tion. Fetch-Client (acts as Collector) may retrieve measurements from Serve= r/Session-Receiver and not be co-located with Session-Sender (acts as MA). = Would Session-Receiver be viewed as MA since Server is part of Controller o= r as MP?
Re= gards,
Greg


On Thu, Mar 13, 2014 at 8:29 AM, <philip.eardley@bt.com>= wrote:

I’m trying to resolve t= he issues raised in WG Last call about the framework http://tool= s.ietf.org/html/draft-ietf-lmap-framework-03

 

= 1.&= nbsp;   Especially if you = weren’t in London, please can you check the slides to make sure you&r= squo;re happy with the proposed consensus on the various issues. http://tools.ietf.org/agenda/89/slides/slides-89-lmap-2.pdf &= nbsp; (ignore slides 5, 6, 7 – see link below instead)<= /span>

2.    I prepar= ed some slides about the MA vs MP terminology in action. Do these examples = help clarify things? They could be turned into some text for the next versi= on of the framework  http://www.leone-project.eu/drupal/sites/default/files/pu= blic_downloads/lmap-framework-examples-13march2014.pdf

 

I plan to work on the framework i-d next week, so= please let me know if you have any comments.

 

Background: A group of us met for a side meeting = in London and (we think) reached consensus on all the open issues. I presen= ted the proposals during the WG meeting in London. We had some good discuss= ion, especially about the terminology for Measurement Peer, which led to co= nsensus round a slightly revised wording, and the suggestion that the i-d s= hould include some explanatory examples, to illustrate the MA vs MP termino= logy in action.

 

Thanks!

Best wishes

phil


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


--001a1136b2629f0cf004f4ff2326-- From nobody Thu Mar 20 00:35:26 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C261A03DF for ; Thu, 20 Mar 2014 00:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 G_lFkcTOsgQt for ; Thu, 20 Mar 2014 00:35:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 781FA1A039D for ; Thu, 20 Mar 2014 00:35:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BA653EAB; Thu, 20 Mar 2014 08:35:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ijM9CCu-I0A8; Thu, 20 Mar 2014 08:35:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 20 Mar 2014 08:35:12 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2794F2002F; Thu, 20 Mar 2014 08:35:12 +0100 (CET) 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 pZmfuwgcLbd0; Thu, 20 Mar 2014 08:35:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 041512002C; Thu, 20 Mar 2014 08:35:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81DF12BD1EAD; Thu, 20 Mar 2014 08:35:09 +0100 (CET) Date: Thu, 20 Mar 2014 08:35:09 +0100 From: Juergen Schoenwaelder To: Greg Mirsky Message-ID: <20140320073509.GA8475@elstar.local> Mail-Followup-To: Greg Mirsky , philip.eardley@bt.com, "lmap@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/H0wQocztG2BouI-LYmOkrpmqFmA Cc: philip.eardley@bt.com, "lmap@ietf.org" Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 07:35:25 -0000 On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > Hi Phil, > I've got a question on: > Basic distinction between MA and Measurement Peer > - MA interacts with Controller and Collector > - MP doesn't > My question What would call a node that doesn't interact with Controller > but does interact with Collector? Would characterize it as MA or MP? Or > you believe that such scenario is not realistic or must not be allowed? How does such a node know to which controller(s) to send data, how frequently, which security credentials to use? Do you assume all this information typically provided by a controller is hardwired? /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 Mar 20 03:54:15 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACF1A06D9 for ; Thu, 20 Mar 2014 03:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 SiTpGpXg9Bbo for ; Thu, 20 Mar 2014 03:54:10 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 031081A06C3 for ; Thu, 20 Mar 2014 03:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1346; q=dns/txt; s=iport; t=1395312841; x=1396522441; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=mavgntPi5LTxgenSvKP29YlFGUNbr7FKKqB0jVHuonc=; b=XmqAakDKvq0Ve3hTShE/WH6y47npF4o9FavSgC3ZjepvVEme+HuRs9jN emuaI8hK/JEnK5zlLLM2nsVcLzH0LMEocRoSKzot+nTRgHa4enQY1C1dw F8QO8yccpBdtNTg8v9nqvhPeVGR92DcuFPv1SCYp6XgF0pFJckT9dzjUN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAFvHKlOQ/khN/2dsb2JhbABagwbAU4MPgR4WdIIlAQEBBDhAEQsYCRYPCQMCAQIBRQYBDAgBAYd10CcXjmyEOAEDmEeGTItkgy0 X-IronPort-AV: E=Sophos;i="4.97,694,1389744000"; d="scan'208";a="5373761" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-4.cisco.com with ESMTP; 20 Mar 2014 10:54:00 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2KArxQm019741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2014 10:54:00 GMT Received: from [10.61.96.49] (dhcp-10-61-96-49.cisco.com [10.61.96.49]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s2KArxxq016435; Thu, 20 Mar 2014 10:53:59 GMT Message-ID: <532AC918.1040608@cisco.com> Date: Thu, 20 Mar 2014 10:55:20 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Greg Mirsky , philip.eardley@bt.com, "lmap@ietf.org" References: <20140320073509.GA8475@elstar.local> In-Reply-To: <20140320073509.GA8475@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Gr06j5sbV7Radf-hTRi1_h-xDuM Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 10:54:13 -0000 On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: >> Hi Phil, >> I've got a question on: >> Basic distinction between MA and Measurement Peer >> - MA interacts with Controller and Collector >> - MP doesn't >> My question What would call a node that doesn't interact with Controller >> but does interact with Collector? Would characterize it as MA or MP? Or >> you believe that such scenario is not realistic or must not be allowed? > How does such a node know to which controller(s) to send data, how > frequently, which security credentials to use? Do you assume all this > information typically provided by a controller is hardwired? +1. A node shouldn't interact with the Collector unless + until it has been instructed to do so by a Controller. Even if the node is pre-set to report to a specific Collector (eg, it's factory programmed), it MUST be possible for a Collector to disable the reporting. (eg, years later when the Collector is no longer in use, or the Collector's IP has been re-assigned.) Arguably it should always be possible for a Controller to reconfigure a device, no matter how simple it is. So basic requirements are surely: (a) enable / disable reports, and (b) set a new Collector address. P. From nobody Thu Mar 20 04:05:01 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCAA1A08B5 for ; Thu, 20 Mar 2014 04:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 7GbYg-YBRmDm for ; Thu, 20 Mar 2014 04:04:55 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5609D1A06C1 for ; Thu, 20 Mar 2014 04:04:54 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 20 Mar 2014 11:03:29 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.203]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 20 Mar 2014 11:04:19 +0000 From: To: , , Date: Thu, 20 Mar 2014 11:04:18 +0000 Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac9EKrg/T7PgZCmxT7G6qhi3x6wXHAAAGxPg Message-ID: References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> In-Reply-To: <532AC918.1040608@cisco.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ed7uLkJ4l36zidX4nDnL-B2j4fw Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 11:04:57 -0000 I agree with this. It is always possible that a node may do something outside the LMAP framewo= rk (perhaps even a MP could ignore Juergen's caveat and, without being inst= ructed by a Controller, send results to a Collector, perhaps even using lma= p's report protocol). It is perfectly ok for people to use some parts of lm= ap in new ways. But I think we should worry about the main use case.=20 Best wishes phil > -----Original Message----- > From: Paul Aitken [mailto:paitken@cisco.com] > Sent: 20 March 2014 10:55 > To: Greg Mirsky; Eardley,PL,Philip,TUB8 R; lmap@ietf.org > Subject: Re: [lmap] Progress on Framework >=20 > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > > On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > >> Hi Phil, > >> I've got a question on: > >> Basic distinction between MA and Measurement Peer > >> - MA interacts with Controller and Collector > >> - MP doesn't > >> My question What would call a node that doesn't interact with > >> Controller but does interact with Collector? Would characterize it > as > >> MA or MP? Or you believe that such scenario is not realistic or must > not be allowed? > > How does such a node know to which controller(s) to send data, how > > frequently, which security credentials to use? Do you assume all this > > information typically provided by a controller is hardwired? >=20 > +1. A node shouldn't interact with the Collector unless + until it has > been instructed to do so by a Controller. >=20 > Even if the node is pre-set to report to a specific Collector (eg, it's > factory programmed), it MUST be possible for a Collector to disable the > reporting. > (eg, years later when the Collector is no longer in use, or the > Collector's IP has been re-assigned.) >=20 > Arguably it should always be possible for a Controller to reconfigure a > device, no matter how simple it is. >=20 > So basic requirements are surely: >=20 > (a) enable / disable reports, and > (b) set a new Collector address. >=20 > P. From nobody Thu Mar 20 04:12:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDBC1A06CF for ; Thu, 20 Mar 2014 04:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.748 X-Spam-Level: X-Spam-Status: No, score=-104.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 QeBK-jmFvvY1 for ; Thu, 20 Mar 2014 04:12:25 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id EC3CF1A06C1 for ; Thu, 20 Mar 2014 04:12:24 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2C6B7CD507D for ; Thu, 20 Mar 2014 12:12:15 +0100 (CET) X-uc3m-safe: yes Received: from dummyhost17.it.uc3m.es (dummyhost0.it.uc3m.es [163.117.139.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 20C57CB4C12 for ; Thu, 20 Mar 2014 12:12:15 +0100 (CET) Message-ID: <532ACD0E.9040900@it.uc3m.es> Date: Thu, 20 Mar 2014 12:12:14 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> In-Reply-To: <532AC918.1040608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Thu, 20 Mar 2014 12:12:15 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20576.006 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6iqLKIhguujaiOdTABwYdpFinU8 Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 11:12:29 -0000 yes, i agree. even if a MA is not initiating measurement tasks, there must be a communication with the controller to schedule the reporting tasks. El 20/03/14 11:55, Paul Aitken escribió: > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: >> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: >>> Hi Phil, >>> I've got a question on: >>> Basic distinction between MA and Measurement Peer >>> - MA interacts with Controller and Collector >>> - MP doesn't >>> My question What would call a node that doesn't interact with >>> Controller >>> but does interact with Collector? Would characterize it as MA or MP? Or >>> you believe that such scenario is not realistic or must not be allowed? >> How does such a node know to which controller(s) to send data, how >> frequently, which security credentials to use? Do you assume all this >> information typically provided by a controller is hardwired? > > +1. A node shouldn't interact with the Collector unless + until it has > been instructed to do so by a Controller. > > Even if the node is pre-set to report to a specific Collector (eg, > it's factory programmed), it MUST be possible for a Collector to > disable the reporting. > (eg, years later when the Collector is no longer in use, or the > Collector's IP has been re-assigned.) > > Arguably it should always be possible for a Controller to reconfigure > a device, no matter how simple it is. > > So basic requirements are surely: > > (a) enable / disable reports, and > (b) set a new Collector address. > > P. > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Thu Mar 20 05:19:18 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510FD1A06CF for ; Thu, 20 Mar 2014 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY8oWc3Qtyx5 for ; Thu, 20 Mar 2014 05:19:11 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id D98161A04F1 for ; Thu, 20 Mar 2014 05:19:11 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-red.research.att.com (Postfix) with ESMTP id 7EE5A5541F0; Thu, 20 Mar 2014 08:24:18 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-azure.research.att.com (Postfix) with ESMTP id DCE67E1F4F; Thu, 20 Mar 2014 08:19:02 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 20 Mar 2014 08:19:02 -0400 From: "MORTON, ALFRED C (AL)" To: marcelo bagnulo braun , "lmap@ietf.org" Date: Thu, 20 Mar 2014 08:19:01 -0400 Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac9ELUytFTCzHnsdQXmp6FGt6lCvFgACGScw Message-ID: <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> In-Reply-To: <532ACD0E.9040900@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RwvK7zzz-9jAAW0ptoVsGt9oHVQ Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 12:19:14 -0000 So here's where I come out on this: Strictly speaking, the MP does not participate in LMAP protocols (in the ty= pical use) and - it assists a measurement function that is governed by an MA by participa= ting in=20 a measurement (or other) protocol. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo > braun > Sent: Thursday, March 20, 2014 7:12 AM > To: lmap@ietf.org > Subject: Re: [lmap] Progress on Framework >=20 > yes, i agree. > even if a MA is not initiating measurement tasks, there must be a > communication with the controller to schedule the reporting tasks. >=20 >=20 >=20 > El 20/03/14 11:55, Paul Aitken escribi=F3: > > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > >> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > >>> Hi Phil, > >>> I've got a question on: > >>> Basic distinction between MA and Measurement Peer > >>> - MA interacts with Controller and Collector > >>> - MP doesn't > >>> My question What would call a node that doesn't interact with > >>> Controller > >>> but does interact with Collector? Would characterize it as MA or MP? > Or > >>> you believe that such scenario is not realistic or must not be > allowed? > >> How does such a node know to which controller(s) to send data, how > >> frequently, which security credentials to use? Do you assume all this > >> information typically provided by a controller is hardwired? > > > > +1. A node shouldn't interact with the Collector unless + until it has > > been instructed to do so by a Controller. > > > > Even if the node is pre-set to report to a specific Collector (eg, > > it's factory programmed), it MUST be possible for a Collector to > > disable the reporting. > > (eg, years later when the Collector is no longer in use, or the > > Collector's IP has been re-assigned.) > > > > Arguably it should always be possible for a Controller to reconfigure > > a device, no matter how simple it is. > > > > So basic requirements are surely: > > > > (a) enable / disable reports, and > > (b) set a new Collector address. > > > > P. > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 20 06:30:22 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EBB1A0740 for ; Thu, 20 Mar 2014 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 BGt7tH1Ceq4I for ; Thu, 20 Mar 2014 06:30:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 79D971A06D2 for ; Thu, 20 Mar 2014 06:30:15 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s2KDU5Kr028502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Mar 2014 08:30:05 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s2KDU4Y4015916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Mar 2014 09:30:04 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.153]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 09:30:04 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: BBF Review - IETF Information Model - Timers Thread-Index: Ac9EQIAdNWRUYdfgQD2hU7GuLpKELQ== Date: Thu, 20 Mar 2014 13:30:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F772B6F10@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F772B6F10US70UWXCHMBA05zam_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/t7ulB4qVG6JNkCg12xV6ATSe8no Subject: [lmap] BBF Review - IETF Information Model - Timers 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, 20 Mar 2014 13:30:20 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F772B6F10US70UWXCHMBA05zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trevor, We reviewed the IETF draft information model as instantiated in a TR-069 (T= R-181) device 2 data model last week. There was a question from William Lupton of Cisco regarding the concept of = Randomness in the Timers of the Information model. I will post it here for comment. * need to define randomness parameters more rigorously, e.g. upper limi= t and lower limit don't obviously relate to (mean,sigma); I am guessing tha= t mean is zero and spread is the same as sigma? also, what is poisson here?= isn't poisson a discrete distribution; also need units and examples Any help would be appreciative BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F772B6F10US70UWXCHMBA05zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trevor,

 

We reviewed the IETF draft information model as inst= antiated in a TR-069 (TR-181) device 2 data model last week.

 

There was a question from William Lupton of Cisco re= garding the concept of Randomness in the Timers of the Information model.

 

I will post it here for comment.

 

  • need to define randomness parameters more = rigorously, e.g. upper limit and lower limit don't obviously relate to (mea= n,sigma); I am guessing that mean is zero and spread is the same as sigma? = also, what is poisson here? isn't poisson a discrete distribution; also need units and examples

Any help would be appreciative

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F772B6F10US70UWXCHMBA05zam_-- From nobody Thu Mar 20 07:05:39 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E381A08DB for ; Thu, 20 Mar 2014 07:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wayBzaJLYUP3 for ; Thu, 20 Mar 2014 07:05:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A31A08D9 for ; Thu, 20 Mar 2014 07:05:15 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 20 Mar 2014 14:03:50 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.17]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 20 Mar 2014 14:04:40 +0000 From: To: , Date: Thu, 20 Mar 2014 14:04:40 +0000 Thread-Topic: BBF Review - IETF Information Model - Timers Thread-Index: Ac9EQIAdNWRUYdfgQD2hU7GuLpKELQAAbvOA Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F772B6F10@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F772B6F10@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D13DA58ECEMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/W_OiGId3C3vp2cdy-vq30BELHUM Subject: Re: [lmap] BBF Review - IETF Information Model - Timers 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, 20 Mar 2014 14:05:33 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D13DA58ECEMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes this does need to be clarified. I was assuming a distribution about the= mean (i.e. the timing given is the mean). The spread would be the standard= deviation (could use mean deviation or something else but I see no advanta= ge as long as we all know what it refers to) and need to change to a float.= The upper and lower cuts would be in seconds +/- the mean (also needs to c= hange to float) and are simply used to trim the function - obviously needed= on a uniform distribution but useful to constrain other functions. I will make all this clear in the next release. As for poisson I think there are 3 options: - Use a continuous form instead - Have the discrete interval implicit in the function choice e.g."po= isson_1_sec" - Add an interval to the information model. I was really thinking about the first, but I don't see the problem with the= second. However I wouldn't do the third unless they was a demonstrable val= ue to supporting discrete functions (rather than continuous versions of the= m). Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 20 March 2014 13:30 To: lmap@ietf.org Subject: [lmap] BBF Review - IETF Information Model - Timers Trevor, We reviewed the IETF draft information model as instantiated in a TR-069 (T= R-181) device 2 data model last week. There was a question from William Lupton of Cisco regarding the concept of = Randomness in the Timers of the Information model. I will post it here for comment. * need to define randomness parameters more rigorously, e.g. upper limit= and lower limit don't obviously relate to (mean,sigma); I am guessing that= mean is zero and spread is the same as sigma? also, what is poisson here? = isn't poisson a discrete distribution; also need units and examples Any help would be appreciative BR, Tim --_000_ED51D9282D1D3942B9438CA8F3372EB72D13DA58ECEMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes this does need to be clarified. I was assuming a distribu= tion about the mean (i.e. the timing given is the mean). The spread would b= e the standard deviation (could use mean deviation or something else but I = see no advantage as long as we all know what it refers to) and need to chan= ge to a float. The upper and lower cuts would be in seconds +/- the mean (a= lso needs to change to float) and are simply used to trim the function R= 11; obviously needed on a uniform distribution but useful to constrain othe= r functions.

 

I will make all this clear in the next release.

 

As for poiss= on I think there are 3 options:

-      =   Use a c= ontinuous form instead

-        Have the discret= e interval implicit in the function choice e.g.“poisson_1_sec”<= o:p>

-        Add an interval to the information mode= l.

=  

I was really thinking about the first, but I don’t see the proble= m with the second. However I wouldn’t do the third unless they was a = demonstrable value to supporting discrete functions (rather than continuous= versions of them).

 

Trevor.

 

 

From: lmap [mailto:lmap-= bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent:<= /b> 20 March 2014 13:30
To: lmap@ietf.org
Subject: [lma= p] BBF Review - IETF Information Model - Timers

=

 

Trevor,

 

We reviewed the IETF draft information model as instantiated in a TR-069 = (TR-181) device 2 data model last week.

 

= There was a question from William Lupton of Cisco regard= ing the concept of Randomness in the Timers of the Information model.<= /o:p>

 

I will post it here for co= mment.

&n= bsp;

  • need t= o define randomness parameters more rigorously, e.g. upper limit and lower = limit don't obviously relate to (mean,sigma); I am guessing that mean is ze= ro and spread is the same as sigma? also, what is poisson here? isn't poiss= on a discrete distribution; also need units and examples<= /li>

Any help would be apprecia= tive

&nbs= p;

BR,

Tim

<= /div>
= --_000_ED51D9282D1D3942B9438CA8F3372EB72D13DA58ECEMV64UKRDdoma_-- From nobody Thu Mar 20 07:24:19 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29E1A03D5 for ; Thu, 20 Mar 2014 07:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 rj53pXmNnaUU for ; Thu, 20 Mar 2014 07:24:14 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id A44BF1A0048 for ; Thu, 20 Mar 2014 07:24:14 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2FA97A02BA; Thu, 20 Mar 2014 10:24:05 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id E69D5A02B7; Thu, 20 Mar 2014 10:24:04 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 10:24:04 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , marcelo bagnulo braun , "lmap@ietf.org" Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac8+w09PTIYfj8AUQTCGd5DdMjlH6wFNHEIAAA4slYAABv3HAAAAlxkAAAJVF4AABC+Q4A== Date: Thu, 20 Mar 2014 14:24:04 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20576.006 X-TM-AS-Result: No--37.412-5.0-31-10 X-imss-scan-details: No--37.412-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20576.006 X-TMASE-Result: 10--37.411600-5.000000 X-TMASE-MatchedRID: fE0JoqABJp3YfPOPCpnfAjiPEKUh+xB+jiWciALpTNPowlt7Drx920HM 02uf2U4pRFUZgMrEu5nqI2wwIftZ422QZfXUxU9feUyVZX4ivrtQCOsAlaxN7wZbeEWcL03V4Wo dnjFW9RQ+oFL5hAX9BvFPDHhQkgxyvzYsuaXOCAXLXx7n52sqBhmyTBaqiJvciavKhODvGLvr+t SA5d5keqEASN2j2qpFZvPVU0HLssUmek8QIa7Urhes/RxhysDbUCwb19dUaUmXaXn+/c+l2nfdR wWexX0rlpcJlK7FTk/0/b5SRad2To+uMz+W0xT5Dko+EYiDQxErHkgIan9a0c2mvbig5LjGHz5c cRN5kLMojlDYdAoPBQ0MnySdeUotYWo9dIuk10BCvapcIkxJX3WT6A/Vdqa08qTRtZpIdQyjxYy RBa/qJeFYM+IjwPfzjaPj0W1qn0SQZS2ujCtcuA== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bvRyRspaPCh5lSTLbLyUvyH03uM Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 14:24:16 -0000 There is nothing in the LMAP frame work to prohibit a rouge reporter. Norma= lly the controller would have to provide the collector's information to the= MA. This would be part of an implementation to make sure reports are comin= g from a commissioned MA in my opinion. /Sharam=20 So here's where I come out on this: Strictly speaking, the MP does not participate in LMAP protocols (in the ty= pical use) and - it assists a measurement function that is governed by an MA by participa= ting in=20 a measurement (or other) protocol. Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo > braun > Sent: Thursday, March 20, 2014 7:12 AM > To: lmap@ietf.org > Subject: Re: [lmap] Progress on Framework >=20 > yes, i agree. > even if a MA is not initiating measurement tasks, there must be a > communication with the controller to schedule the reporting tasks. >=20 >=20 >=20 > El 20/03/14 11:55, Paul Aitken escribi=F3: > > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > >> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > >>> Hi Phil, > >>> I've got a question on: > >>> Basic distinction between MA and Measurement Peer > >>> - MA interacts with Controller and Collector > >>> - MP doesn't > >>> My question What would call a node that doesn't interact with > >>> Controller > >>> but does interact with Collector? Would characterize it as MA or MP? > Or > >>> you believe that such scenario is not realistic or must not be > allowed? > >> How does such a node know to which controller(s) to send data, how > >> frequently, which security credentials to use? Do you assume all this > >> information typically provided by a controller is hardwired? > > > > +1. A node shouldn't interact with the Collector unless + until it has > > been instructed to do so by a Controller. > > > > Even if the node is pre-set to report to a specific Collector (eg, > > it's factory programmed), it MUST be possible for a Collector to > > disable the reporting. > > (eg, years later when the Collector is no longer in use, or the > > Collector's IP has been re-assigned.) > > > > Arguably it should always be possible for a Controller to reconfigure > > a device, no matter how simple it is. > > > > So basic requirements are surely: > > > > (a) enable / disable reports, and > > (b) set a new Collector address. > > > > P. > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 20 07:27:25 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3896E1A03EF for ; Thu, 20 Mar 2014 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIM4fb22FFdQ for ; Thu, 20 Mar 2014 07:27:22 -0700 (PDT) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4337D1A03CA for ; Thu, 20 Mar 2014 07:27:22 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 3E42055428C; Thu, 20 Mar 2014 10:32:29 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.242]) by mail-blue.research.att.com (Postfix) with ESMTP id 57952F0143; Thu, 20 Mar 2014 10:27:13 -0400 (EDT) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Thu, 20 Mar 2014 10:27:13 -0400 From: "MORTON, ALFRED C (AL)" To: Sharam Hakimi , marcelo bagnulo braun , "lmap@ietf.org" Date: Thu, 20 Mar 2014 10:27:12 -0400 Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac8+w09PTIYfj8AUQTCGd5DdMjlH6wFNHEIAAA4slYAABv3HAAAAlxkAAAJVF4AABC+Q4AAIKvfQ Message-ID: <2845723087023D4CB5114223779FA9C8017910CF02@njfpsrvexg8.research.att.com> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/R_c4g_TadzGh0QvQQCVwgAGIQGE Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 14:27:24 -0000 to address Dan's Last Call comment, there will be material in the security section to address this attack. Al, assuming s/rouge/rogue/ is what you meant > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Thursday, March 20, 2014 10:24 AM > To: MORTON, ALFRED C (AL); marcelo bagnulo braun; lmap@ietf.org > Subject: RE: [lmap] Progress on Framework >=20 > There is nothing in the LMAP frame work to prohibit a rouge reporter. > Normally the controller would have to provide the collector's information > to the MA. This would be part of an implementation to make sure reports > are coming from a commissioned MA in my opinion. >=20 > /Sharam >=20 >=20 > So here's where I come out on this: >=20 > Strictly speaking, the MP does not participate in LMAP protocols (in the > typical use) > and > - it assists a measurement function that is governed by an MA by > participating in > a measurement (or other) protocol. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo > > braun > > Sent: Thursday, March 20, 2014 7:12 AM > > To: lmap@ietf.org > > Subject: Re: [lmap] Progress on Framework > > > > yes, i agree. > > even if a MA is not initiating measurement tasks, there must be a > > communication with the controller to schedule the reporting tasks. > > > > > > > > El 20/03/14 11:55, Paul Aitken escribi=F3: > > > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > > >> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > > >>> Hi Phil, > > >>> I've got a question on: > > >>> Basic distinction between MA and Measurement Peer > > >>> - MA interacts with Controller and Collector > > >>> - MP doesn't > > >>> My question What would call a node that doesn't interact with > > >>> Controller > > >>> but does interact with Collector? Would characterize it as MA or MP= ? > > Or > > >>> you believe that such scenario is not realistic or must not be > > allowed? > > >> How does such a node know to which controller(s) to send data, how > > >> frequently, which security credentials to use? Do you assume all thi= s > > >> information typically provided by a controller is hardwired? > > > > > > +1. A node shouldn't interact with the Collector unless + until it ha= s > > > been instructed to do so by a Controller. > > > > > > Even if the node is pre-set to report to a specific Collector (eg, > > > it's factory programmed), it MUST be possible for a Collector to > > > disable the reporting. > > > (eg, years later when the Collector is no longer in use, or the > > > Collector's IP has been re-assigned.) > > > > > > Arguably it should always be possible for a Controller to reconfigure > > > a device, no matter how simple it is. > > > > > > So basic requirements are surely: > > > > > > (a) enable / disable reports, and > > > (b) set a new Collector address. > > > > > > P. > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 20 07:38:33 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D51A08B3 for ; Thu, 20 Mar 2014 07:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 zNuUV5RG1UAG for ; Thu, 20 Mar 2014 07:38:28 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD41A076C for ; Thu, 20 Mar 2014 07:38:28 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5BEF8A02C1; Thu, 20 Mar 2014 10:38:19 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 07E7DA02C0; Thu, 20 Mar 2014 10:38:19 -0400 (EDT) Received: from SPQCMBX02.exfo.com ([169.254.2.14]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 10:38:18 -0400 From: Sharam Hakimi To: "MORTON, ALFRED C (AL)" , marcelo bagnulo braun , "lmap@ietf.org" Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac8+w09PTIYfj8AUQTCGd5DdMjlH6wFNHEIAAA4slYAABv3HAAAAlxkAAAJVF4AABC+Q4AAIKvfQAA/qSbA= Date: Thu, 20 Mar 2014 14:38:18 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7CA40@SPQCMBX02.exfo.com> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> <2845723087023D4CB5114223779FA9C8017910CF02@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8017910CF02@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.36.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1017-20576.006 X-TM-AS-Result: No--43.550-5.0-31-10 X-imss-scan-details: No--43.550-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20576.006 X-TMASE-Result: 10--43.549700-5.000000 X-TMASE-MatchedRID: WMT2WRIkHPMDJrf2+hNOhTOb4QjG+dWPQPCWRE0Lo8JaW2Ktn+I8/i2+ 3JbkB2Ht1TWLwszMfptQLYg6E04dN9cUNjoF7YuVy18e5+drKgZH23kMVk85ybV5fSMRD1zqecZ f3B8j81q0gVrq9RizufOmfW1vc47IIdTGBwYA2nyv2CWpup/ZtGgU1o1xV13fu0zRU6eX8CGA1y 0tmGNVYnF7+YArNpT4eP6A/U6acdVPB4rXagQZ+5pWgCLYjjT9s4fSO+RfYFz/kSkIIR45Ho+1b ntEYE/1nD2iyuK1mqyKgNi6MQMQWEs/3Jy4VTgvd0i3TvT7AKU7ikpJrsu/6KXJ9vMysD/C/JNG PFwi6g29zsLeDLxbz++BdjXdPRlqgZi/ORh+nqCHZXNSWjgdU8MdI0UcXEHzydovWuL+KVfbNQh 85GhqIhFbcWj6ErewHmGY/o4z88loMCLywE0ygcC4UUZr4lSF+gD2vYtOFhgqtq5d3cxkNQP90f JP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FAAuXkCDKdq8ri2rnbBF6uT2v60 Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 14:38:31 -0000 Sorry, yes rogue is what I meant. Typing too fast. /Sharam to address Dan's Last Call comment, there will be material in the security section to address this attack. Al, assuming s/rouge/rogue/ is what you meant > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Thursday, March 20, 2014 10:24 AM > To: MORTON, ALFRED C (AL); marcelo bagnulo braun; lmap@ietf.org > Subject: RE: [lmap] Progress on Framework >=20 > There is nothing in the LMAP frame work to prohibit a rouge reporter. > Normally the controller would have to provide the collector's information > to the MA. This would be part of an implementation to make sure reports > are coming from a commissioned MA in my opinion. >=20 > /Sharam >=20 >=20 > So here's where I come out on this: >=20 > Strictly speaking, the MP does not participate in LMAP protocols (in the > typical use) > and > - it assists a measurement function that is governed by an MA by > participating in > a measurement (or other) protocol. >=20 > Al >=20 > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo > > braun > > Sent: Thursday, March 20, 2014 7:12 AM > > To: lmap@ietf.org > > Subject: Re: [lmap] Progress on Framework > > > > yes, i agree. > > even if a MA is not initiating measurement tasks, there must be a > > communication with the controller to schedule the reporting tasks. > > > > > > > > El 20/03/14 11:55, Paul Aitken escribi=F3: > > > On 20/03/2014 07:35, Juergen Schoenwaelder wrote: > > >> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: > > >>> Hi Phil, > > >>> I've got a question on: > > >>> Basic distinction between MA and Measurement Peer > > >>> - MA interacts with Controller and Collector > > >>> - MP doesn't > > >>> My question What would call a node that doesn't interact with > > >>> Controller > > >>> but does interact with Collector? Would characterize it as MA or MP= ? > > Or > > >>> you believe that such scenario is not realistic or must not be > > allowed? > > >> How does such a node know to which controller(s) to send data, how > > >> frequently, which security credentials to use? Do you assume all thi= s > > >> information typically provided by a controller is hardwired? > > > > > > +1. A node shouldn't interact with the Collector unless + until it ha= s > > > been instructed to do so by a Controller. > > > > > > Even if the node is pre-set to report to a specific Collector (eg, > > > it's factory programmed), it MUST be possible for a Collector to > > > disable the reporting. > > > (eg, years later when the Collector is no longer in use, or the > > > Collector's IP has been re-assigned.) > > > > > > Arguably it should always be possible for a Controller to reconfigure > > > a device, no matter how simple it is. > > > > > > So basic requirements are surely: > > > > > > (a) enable / disable reports, and > > > (b) set a new Collector address. > > > > > > P. > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Mar 20 07:47:45 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D981A074E for ; Thu, 20 Mar 2014 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.748 X-Spam-Level: X-Spam-Status: No, score=-104.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 gr28LYctlqKE for ; Thu, 20 Mar 2014 07:47:39 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD811A08E6 for ; Thu, 20 Mar 2014 07:47:39 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 282C58AA316 for ; Thu, 20 Mar 2014 15:47:29 +0100 (CET) X-uc3m-safe: yes Received: from [163.117.203.118] (unknown [163.117.203.118]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id BFFB98AA2E7 for ; Thu, 20 Mar 2014 15:47:28 +0100 (CET) Message-ID: <532AFF7F.3070903@it.uc3m.es> Date: Thu, 20 Mar 2014 15:47:27 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: lmap@ietf.org References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Thu, 20 Mar 2014 15:47:29 +0100 (CET) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20576.006 X-TM-AS-Result: No--34.086-7.0-31-1 X-imss-scan-details: No--34.086-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/S0MfKb81wOVa5Y2hN_Hzrjk1MYU Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 14:47:43 -0000 In any case, imh the defintion of an MP should state that the MP does not communicate neither with the controller nor the collector. If it has communication with any of these elements, it is considered an MA. I think the important point is to make a clear distinction so to have a proper defintion El 20/03/14 15:24, Sharam Hakimi escribió: > There is nothing in the LMAP frame work to prohibit a rouge reporter. Normally the controller would have to provide the collector's information to the MA. This would be part of an implementation to make sure reports are coming from a commissioned MA in my opinion. > > /Sharam > > > So here's where I come out on this: > > Strictly speaking, the MP does not participate in LMAP protocols (in the typical use) > and > - it assists a measurement function that is governed by an MA by participating in > a measurement (or other) protocol. > > Al > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo >> braun >> Sent: Thursday, March 20, 2014 7:12 AM >> To: lmap@ietf.org >> Subject: Re: [lmap] Progress on Framework >> >> yes, i agree. >> even if a MA is not initiating measurement tasks, there must be a >> communication with the controller to schedule the reporting tasks. >> >> >> >> El 20/03/14 11:55, Paul Aitken escribió: >>> On 20/03/2014 07:35, Juergen Schoenwaelder wrote: >>>> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: >>>>> Hi Phil, >>>>> I've got a question on: >>>>> Basic distinction between MA and Measurement Peer >>>>> - MA interacts with Controller and Collector >>>>> - MP doesn't >>>>> My question What would call a node that doesn't interact with >>>>> Controller >>>>> but does interact with Collector? Would characterize it as MA or MP? >> Or >>>>> you believe that such scenario is not realistic or must not be >> allowed? >>>> How does such a node know to which controller(s) to send data, how >>>> frequently, which security credentials to use? Do you assume all this >>>> information typically provided by a controller is hardwired? >>> +1. A node shouldn't interact with the Collector unless + until it has >>> been instructed to do so by a Controller. >>> >>> Even if the node is pre-set to report to a specific Collector (eg, >>> it's factory programmed), it MUST be possible for a Collector to >>> disable the reporting. >>> (eg, years later when the Collector is no longer in use, or the >>> Collector's IP has been re-assigned.) >>> >>> Arguably it should always be possible for a Controller to reconfigure >>> a device, no matter how simple it is. >>> >>> So basic requirements are surely: >>> >>> (a) enable / disable reports, and >>> (b) set a new Collector address. >>> >>> P. >>> >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Thu Mar 20 09:55:16 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06D1A08C7 for ; Thu, 20 Mar 2014 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHZqaDhCskmL for ; Thu, 20 Mar 2014 09:55:13 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECEF1A07C5 for ; Thu, 20 Mar 2014 09:55:12 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so1258278veb.38 for ; Thu, 20 Mar 2014 09:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9X9DKEp6ekXqIqCUdeIFd8nkHyMUco//Sc1YZm2dgYE=; b=icGGxa4BGpBTyOflClCrQgYrh0RdBLbgL5oONIYwCLmks1mYQumsjn34z03dDsHdgK rnuJwNZ51eORUmjiY3Mb7XOVAMg6pk/QIJE+gtQg7/JZJ7Sjr85d2ZUjDtyTxKYd8cHE 16vO2sWedg5JETZlF9KmAiLr16lNvVM+Df18Zm/ieEYiNHK/m5fCzVglJ1FUGzJWKQdz Lu37iLfUbqjpfLe1t6GIaEQPt/vXicAHbzTIO8m1rrKg3a3MwEuqYA5fNoI2Eo4UBsvX 8n67JvKrFNb7w/6udAXh5dDTA95usRvYrZ4Tm8h8N98eViRutWXLmEOEp//bvAK4vhyp vLJw== MIME-Version: 1.0 X-Received: by 10.58.74.201 with SMTP id w9mr690437vev.56.1395334503858; Thu, 20 Mar 2014 09:55:03 -0700 (PDT) Received: by 10.220.108.132 with HTTP; Thu, 20 Mar 2014 09:55:03 -0700 (PDT) In-Reply-To: <532AFF7F.3070903@it.uc3m.es> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> <532AFF7F.3070903@it.uc3m.es> Date: Thu, 20 Mar 2014 09:55:03 -0700 Message-ID: From: Greg Mirsky To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=047d7bacb77072066004f50ca198 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5sTT-_QVMracTUklFvDXE_M_gbk Cc: "lmap@ietf.org" Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 16:55:15 -0000 --047d7bacb77072066004f50ca198 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo, I agree and clarification is what I've asked about initially. As possible way for MP to obtain information about Collector I've been thinking of bootstrapping process, similar to bootstrapping MA with Controller, security and etc. information. Would LMAP-wise bootstrapping apply to MP? What may be scope of it, if bootstrapping MP is required? And what is optional? Regards, Greg On Thu, Mar 20, 2014 at 7:47 AM, marcelo bagnulo braun wrote: > In any case, imh the defintion of an MP should state that the MP does not > communicate neither with the controller nor the collector. If it has > communication with any of these elements, it is considered an MA. > > I think the important point is to make a clear distinction so to have a > proper defintion > > El 20/03/14 15:24, Sharam Hakimi escribi=F3: > > There is nothing in the LMAP frame work to prohibit a rouge reporter. >> Normally the controller would have to provide the collector's informatio= n >> to the MA. This would be part of an implementation to make sure reports = are >> coming from a commissioned MA in my opinion. >> >> /Sharam >> >> >> So here's where I come out on this: >> >> Strictly speaking, the MP does not participate in LMAP protocols (in the >> typical use) >> and >> - it assists a measurement function that is governed by an MA by >> participating in >> a measurement (or other) protocol. >> >> Al >> >> -----Original Message----- >>> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo >>> braun >>> Sent: Thursday, March 20, 2014 7:12 AM >>> To: lmap@ietf.org >>> Subject: Re: [lmap] Progress on Framework >>> >>> yes, i agree. >>> even if a MA is not initiating measurement tasks, there must be a >>> communication with the controller to schedule the reporting tasks. >>> >>> >>> >>> El 20/03/14 11:55, Paul Aitken escribi=F3: >>> >>>> On 20/03/2014 07:35, Juergen Schoenwaelder wrote: >>>> >>>>> On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote: >>>>> >>>>>> Hi Phil, >>>>>> I've got a question on: >>>>>> Basic distinction between MA and Measurement Peer >>>>>> - MA interacts with Controller and Collector >>>>>> - MP doesn't >>>>>> My question What would call a node that doesn't interact with >>>>>> Controller >>>>>> but does interact with Collector? Would characterize it as MA or MP? >>>>>> >>>>> Or >>> >>>> you believe that such scenario is not realistic or must not be >>>>>> >>>>> allowed? >>> >>>> How does such a node know to which controller(s) to send data, how >>>>> frequently, which security credentials to use? Do you assume all this >>>>> information typically provided by a controller is hardwired? >>>>> >>>> +1. A node shouldn't interact with the Collector unless + until it has >>>> been instructed to do so by a Controller. >>>> >>>> Even if the node is pre-set to report to a specific Collector (eg, >>>> it's factory programmed), it MUST be possible for a Collector to >>>> disable the reporting. >>>> (eg, years later when the Collector is no longer in use, or the >>>> Collector's IP has been re-assigned.) >>>> >>>> Arguably it should always be possible for a Controller to reconfigure >>>> a device, no matter how simple it is. >>>> >>>> So basic requirements are surely: >>>> >>>> (a) enable / disable reports, and >>>> (b) set a new Collector address. >>>> >>>> P. >>>> >>>> _______________________________________________ >>>> lmap mailing list >>>> lmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lmap >>>> >>>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >> >> _______________________________________________ >> 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 > --047d7bacb77072066004f50ca198 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
I agree and clari= fication is what I've asked about initially.
As possible way f= or MP to obtain information about Collector I've been thinking of boots= trapping process, similar to bootstrapping MA with Controller, security and= etc. information. Would LMAP-wise bootstrapping apply to MP? What may be s= cope of it, if bootstrapping MP is required? And what is optional?

Regards,
Greg



On Thu, M= ar 20, 2014 at 7:47 AM, marcelo bagnulo braun <marcelo@it.uc3m.es>= wrote:
In any case, imh the defintion of an MP shou= ld state that the MP does not communicate neither with the controller nor t= he collector. If it has communication with any of these elements, it is con= sidered an MA.

I think the important point is to make a clear distinction so to have a pro= per defintion

El 20/03/14 15:24, Sharam Hakimi escribi=F3:

There is nothing in the LMAP frame work to prohibit a rouge reporter. Norma= lly the controller would have to provide the collector's information to= the MA. This would be part of an implementation to make sure reports are c= oming from a commissioned MA in my opinion.

/Sharam


So here's where I come out on this:

Strictly speaking, the MP does not participate in LMAP protocols (in the ty= pical use)
and
=A0 - it assists a measurement function that is governed by an MA by partic= ipating in
=A0 =A0 a measurement (or other) protocol.

Al

-----Original Message-----
From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of marcelo bagnulo
braun
Sent: Thursday, March 20, 2014 7:12 AM
To: lmap@ietf.org Subject: Re: [lmap] Progress on Framework

yes, i agree.
even if a MA is not initiating measurement tasks, there must be a
communication with the controller to schedule the reporting tasks.



El 20/03/14 11:55, Paul Aitken escribi=F3:
On 20/03/2014 07:35, Juergen Schoenwaelder wrote:
On Wed, Mar 19, 2014 at 05:49:18PM -0700, Greg Mirsky wrote:
Hi Phil,
I've got a question on:
Basic =A0distinction =A0between =A0MA =A0and =A0Measurement =A0Peer
- MA =A0interacts =A0with =A0Controller =A0and =A0Collector
- MP =A0doesn't
My question What would call a node that doesn't interact with
Controller
but does interact with Collector? Would characterize it as MA or MP?
Or
you believe that such scenario is not realistic or must not be
allowed?
How does such a node know to which controller(s) to send data, how
frequently, which security credentials to use? Do you assume all this
information typically provided by a controller is hardwired?
+1. A node shouldn't interact with the Collector unless + until it has<= br> been instructed to do so by a Controller.

Even if the node is pre-set to report to a specific Collector (eg,
it's factory programmed), it MUST be possible for a Collector to
disable the reporting.
(eg, years later when the Collector is no longer in use, or the
Collector's IP has been re-assigned.)

Arguably it should always be possible for a Controller to reconfigure
a device, no matter how simple it is.

So basic requirements are surely:

=A0 =A0 =A0(a) enable / disable reports, and
=A0 =A0 =A0(b) set a new Collector address.

P.

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

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

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


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

--047d7bacb77072066004f50ca198-- From nobody Thu Mar 20 10:16:08 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844341A0700 for ; Thu, 20 Mar 2014 10:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] 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 QNm_8bJh9DV8 for ; Thu, 20 Mar 2014 10:16:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5661A03BF for ; Thu, 20 Mar 2014 10:16:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5378EAB; Thu, 20 Mar 2014 18:15:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jjTHIFn1jiEF; Thu, 20 Mar 2014 18:15:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 20 Mar 2014 18:15:54 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C1322002F; Thu, 20 Mar 2014 18:15:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cd8EAOH-Oo8p; Thu, 20 Mar 2014 18:15:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83B0A2002C; Thu, 20 Mar 2014 18:15:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7ACF62BD3896; Thu, 20 Mar 2014 18:15:50 +0100 (CET) Date: Thu, 20 Mar 2014 18:15:50 +0100 From: Juergen Schoenwaelder To: Greg Mirsky Message-ID: <20140320171550.GA10349@elstar.local> Mail-Followup-To: Greg Mirsky , marcelo bagnulo braun , "lmap@ietf.org" References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> <532AFF7F.3070903@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cClCz80KXY0I7ytTfXwNjyMy1-s Cc: marcelo bagnulo braun , "lmap@ietf.org" Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 17:16:06 -0000 On Thu, Mar 20, 2014 at 09:55:03AM -0700, Greg Mirsky wrote: > Hi Marcelo, > I agree and clarification is what I've asked about initially. > As possible way for MP to obtain information about Collector I've been > thinking of bootstrapping process, similar to bootstrapping MA with > Controller, security and etc. information. Would LMAP-wise bootstrapping > apply to MP? What may be scope of it, if bootstrapping MP is required? And > what is optional? Quoting the framework: The MA needs to be bootstrapped with initial details about its Controller, including authentication credentials. The LMAP WG considers the bootstrap process, since it affects the Information Model. However, it does not define a bootstrap protocol, since it is likely to be technology specific and could be defined by the Broadband Forum, CableLabs or IEEE depending on the device. Possible protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN Management Protocol (CWMP) from the Auto Configuration Server (ACS) (as specified in TR-069). /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 Mar 20 10:22:31 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFD91A07C1 for ; Thu, 20 Mar 2014 10:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 L-KmpwvHMMVu for ; Thu, 20 Mar 2014 10:22:27 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA41A0700 for ; Thu, 20 Mar 2014 10:22:27 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ac32b235.2b3ad3084940.6446289.00-2473.16849655.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 20 Mar 2014 17:22:18 +0000 (UTC) X-MXL-Hash: 532b23ca66c817ea-3c4e8af4ffc7e73d03e0fe4d72660856a4bca0df Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 3c32b235.0.6446218.00-2355.16849474.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 20 Mar 2014 17:22:13 +0000 (UTC) X-MXL-Hash: 532b23c516ab6f1d-1268e8808743645c5df70f3c63589c82dd8ed9ad 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 s2KHMALT004733; Thu, 20 Mar 2014 13:22:10 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2KHM3X7004625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2014 13:22:05 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 20 Mar 2014 17:22:00 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 13:22:00 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , Greg Mirsky Thread-Topic: [lmap] Progress on Framework Thread-Index: Ac8+w09PTIYfj8AUQTCGd5DdMjlH6wFNHEIAAA4slYAABv3HAAAAlxkAAAJVF4AABC+Q4AAA/4mAAAR01YAAALnRAAAIO+YQ Date: Thu, 20 Mar 2014 17:22:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611304108FA@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <20140320073509.GA8475@elstar.local> <532AC918.1040608@cisco.com> <532ACD0E.9040900@it.uc3m.es> <2845723087023D4CB5114223779FA9C8017910CEAF@njfpsrvexg8.research.att.com> <89294A6F3C6C91459E52E4128C4B02B7CA08@SPQCMBX02.exfo.com> <532AFF7F.3070903@it.uc3m.es> <20140320171550.GA10349@elstar.local> In-Reply-To: <20140320171550.GA10349@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.213.57] 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=LqUlPAhc c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=8TqdIOG6R00A:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h0n9LFXCa] X-AnalysisOut: [m3qmpLzdasA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/619O9zuvIP2IBv-UNUFZkcA1B9M Cc: marcelo bagnulo braun , "lmap@ietf.org" Subject: Re: [lmap] Progress on Framework 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, 20 Mar 2014 17:22:29 -0000 > On Thu, Mar 20, 2014 at 09:55:03AM -0700, Greg Mirsky wrote: > > Hi Marcelo, > > I agree and clarification is what I've asked about initially. > > As possible way for MP to obtain information about Collector I've been > > thinking of bootstrapping process, similar to bootstrapping MA with > > Controller, security and etc. information. Would LMAP-wise > > bootstrapping apply to MP? What may be scope of it, if bootstrapping > > MP is required? And what is optional? >=20 > Quoting the framework: >=20 > The MA needs to be bootstrapped with initial details about its > Controller, including authentication credentials. The LMAP WG > considers the bootstrap process, since it affects the Information > Model. However, it does not define a bootstrap protocol, since it is > likely to be technology specific and could be defined by the > Broadband Forum, CableLabs or IEEE depending on the device. Possible > protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN > Management > Protocol (CWMP) from the Auto Configuration Server (ACS) (as > specified in TR-069). I wonder if I could re-suggest what I'd said earlier, that maybe the defini= tion of MP is: A function that assists a Measurement Agent with Measurement Tasks. All oth= er interfaces to a MP are undefined. Barbara From nobody Thu Mar 20 10:29:42 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DAF1A08EE for ; Thu, 20 Mar 2014 10:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.147 X-Spam-Level: X-Spam-Status: No, score=-104.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 h4p9i94ixK7J for ; Thu, 20 Mar 2014 10:29:38 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 97BDA1A07F6 for ; Thu, 20 Mar 2014 10:29:37 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DCC3A8B70F6; Thu, 20 Mar 2014 18:29:27 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.98.89.181] (181.5.132.37.dynamic.jazztel.es [37.132.5.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id D6801766E96; Thu, 20 Mar 2014 18:29:21 +0100 (CET) Date: Thu, 20 Mar 2014 18:29:00 +0100 Message-ID: Importance: normal From: marcelo bagnulo braun To: bs7652@att.com, j.schoenwaelder@jacobs-university.de, gregimirsky@gmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_22470322809930" X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20576.006 X-TM-AS-Result: No--25.232-7.0-31-1 X-imss-scan-details: No--25.232-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/k4xvpFfOYXTuGWtpodSTpheA_Ns Cc: lmap@ietf.org Subject: Re: [lmap] Progress on Framework X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: marcelo bagnulo braun List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:29:41 -0000 ----_com.android.email_22470322809930 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 UmlnaHQgYnV0IGkgYmVsaWV2ZSB3ZSBzaG91bGQgc3RhdGUgdGhhdCB0aGUgbXAgZG9lc250IGNv bXVuaWNhdGUgbmVpdGhlciB0byB0aGUgY29udHJvbGxlciBub3IgY29sZWN0b3IuIElmIG5vdCB0 aGVyZSBpcyBubyBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIG1hIGFuZCBtcAoKCkVudmlhZG8g ZGUgU2Ftc3VuZyBNb2JpbGUiU1RBUkssIEJBUkJBUkEgSCIgPGJzNzY1MkBhdHQuY29tPiBlc2Ny aWJpw7M6Cj4gT24gVGh1LCBNYXIgMjAsIDIwMTQgYXQgMDk6NTU6MDNBTSAtMDcwMCwgR3JlZyBN aXJza3kgd3JvdGU6Cj4gPiBIaSBNYXJjZWxvLAo+ID4gSSBhZ3JlZSBhbmQgY2xhcmlmaWNhdGlv biBpcyB3aGF0IEkndmUgYXNrZWQgYWJvdXQgaW5pdGlhbGx5Lgo+ID4gQXMgcG9zc2libGUgd2F5 IGZvciBNUCB0byBvYnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgQ29sbGVjdG9yIEkndmUgYmVlbgo+ ID4gdGhpbmtpbmcgb2YgYm9vdHN0cmFwcGluZyBwcm9jZXNzLCBzaW1pbGFyIHRvIGJvb3RzdHJh cHBpbmcgTUEgd2l0aAo+ID4gQ29udHJvbGxlciwgc2VjdXJpdHkgYW5kIGV0Yy4gaW5mb3JtYXRp b24uIFdvdWxkIExNQVAtd2lzZQo+ID4gYm9vdHN0cmFwcGluZyBhcHBseSB0byBNUD8gV2hhdCBt YXkgYmUgc2NvcGUgb2YgaXQsIGlmIGJvb3RzdHJhcHBpbmcKPiA+IE1QIGlzIHJlcXVpcmVkPyBB bmQgd2hhdCBpcyBvcHRpb25hbD8KPiAKPiBRdW90aW5nIHRoZSBmcmFtZXdvcms6Cj4gCj7CoMKg wqAgVGhlIE1BIG5lZWRzIHRvIGJlIGJvb3RzdHJhcHBlZCB3aXRoIGluaXRpYWwgZGV0YWlscyBh Ym91dCBpdHMKPsKgwqDCoCBDb250cm9sbGVyLCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24gY3Jl ZGVudGlhbHMuwqAgVGhlIExNQVAgV0cKPsKgwqDCoCBjb25zaWRlcnMgdGhlIGJvb3RzdHJhcCBw cm9jZXNzLCBzaW5jZSBpdCBhZmZlY3RzIHRoZSBJbmZvcm1hdGlvbgo+wqDCoMKgIE1vZGVsLsKg IEhvd2V2ZXIsIGl0IGRvZXMgbm90IGRlZmluZSBhIGJvb3RzdHJhcCBwcm90b2NvbCwgc2luY2Ug aXQgaXMKPsKgwqDCoCBsaWtlbHkgdG8gYmUgdGVjaG5vbG9neSBzcGVjaWZpYyBhbmQgY291bGQg YmUgZGVmaW5lZCBieSB0aGUKPsKgwqDCoCBCcm9hZGJhbmQgRm9ydW0sIENhYmxlTGFicyBvciBJ RUVFIGRlcGVuZGluZyBvbiB0aGUgZGV2aWNlLsKgIFBvc3NpYmxlCj7CoMKgwqAgcHJvdG9jb2xz IGFyZSBTTk1QLCBORVRDT05GIG9yIChmb3IgSG9tZSBHYXRld2F5cykgQ1BFIFdBTgo+IE1hbmFn ZW1lbnQKPsKgwqDCoCBQcm90b2NvbCAoQ1dNUCkgZnJvbSB0aGUgQXV0byBDb25maWd1cmF0aW9u IFNlcnZlciAoQUNTKSAoYXMKPsKgwqDCoCBzcGVjaWZpZWQgaW4gVFItMDY5KS4KCkkgd29uZGVy IGlmIEkgY291bGQgcmUtc3VnZ2VzdCB3aGF0IEknZCBzYWlkIGVhcmxpZXIsIHRoYXQgbWF5YmUg dGhlIGRlZmluaXRpb24gb2YgTVAgaXM6CkEgZnVuY3Rpb24gdGhhdCBhc3Npc3RzIGEgTWVhc3Vy ZW1lbnQgQWdlbnQgd2l0aCBNZWFzdXJlbWVudCBUYXNrcy4gQWxsIG90aGVyIGludGVyZmFjZXMg dG8gYSBNUCBhcmUgdW5kZWZpbmVkLgoKQmFyYmFyYQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbG1hcCBtYWlsaW5nIGxpc3QKbG1hcEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAK ----_com.android.email_22470322809930 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5SaWdodCBidXQgaSBiZWxp ZXZlIHdlIHNob3VsZCBzdGF0ZSB0aGF0IHRoZSBtcCBkb2VzbnQgY29tdW5pY2F0ZSBuZWl0aGVy IHRvIHRoZSBjb250cm9sbGVyIG5vciBjb2xlY3Rvci4gSWYgbm90IHRoZXJlIGlzIG5vIGNsZWFy IGRpc3RpbmN0aW9uIGJldHdlZW4gbWEgYW5kIG1wPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6NzUlO2NvbG9yOiM1NzU3NTciPkVu dmlhZG8gZGUgU2Ftc3VuZyBNb2JpbGU8L2Rpdj48L2Rpdj4gPGJyPiJTVEFSSywgQkFSQkFSQSBI IiAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7IGVzY3JpYmnDszo8YnI+PGJyPiZndDsgT24gVGh1LCBN YXIgMjAsIDIwMTQgYXQgMDk6NTU6MDNBTSAtMDcwMCwgR3JlZyBNaXJza3kgd3JvdGU6PGJyPiZn dDsgJmd0OyBIaSBNYXJjZWxvLDxicj4mZ3Q7ICZndDsgSSBhZ3JlZSBhbmQgY2xhcmlmaWNhdGlv biBpcyB3aGF0IEkndmUgYXNrZWQgYWJvdXQgaW5pdGlhbGx5Ljxicj4mZ3Q7ICZndDsgQXMgcG9z c2libGUgd2F5IGZvciBNUCB0byBvYnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgQ29sbGVjdG9yIEkn dmUgYmVlbjxicj4mZ3Q7ICZndDsgdGhpbmtpbmcgb2YgYm9vdHN0cmFwcGluZyBwcm9jZXNzLCBz aW1pbGFyIHRvIGJvb3RzdHJhcHBpbmcgTUEgd2l0aDxicj4mZ3Q7ICZndDsgQ29udHJvbGxlciwg c2VjdXJpdHkgYW5kIGV0Yy4gaW5mb3JtYXRpb24uIFdvdWxkIExNQVAtd2lzZTxicj4mZ3Q7ICZn dDsgYm9vdHN0cmFwcGluZyBhcHBseSB0byBNUD8gV2hhdCBtYXkgYmUgc2NvcGUgb2YgaXQsIGlm IGJvb3RzdHJhcHBpbmc8YnI+Jmd0OyAmZ3Q7IE1QIGlzIHJlcXVpcmVkPyBBbmQgd2hhdCBpcyBv cHRpb25hbD88YnI+Jmd0OyA8YnI+Jmd0OyBRdW90aW5nIHRoZSBmcmFtZXdvcms6PGJyPiZndDsg PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIE1BIG5lZWRzIHRvIGJlIGJvb3RzdHJhcHBl ZCB3aXRoIGluaXRpYWwgZGV0YWlscyBhYm91dCBpdHM8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBDb250cm9sbGVyLCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMuJm5ic3A7 IFRoZSBMTUFQIFdHPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uc2lkZXJzIHRoZSBib290 c3RyYXAgcHJvY2Vzcywgc2luY2UgaXQgYWZmZWN0cyB0aGUgSW5mb3JtYXRpb248YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBNb2RlbC4mbmJzcDsgSG93ZXZlciwgaXQgZG9lcyBub3QgZGVmaW5l IGEgYm9vdHN0cmFwIHByb3RvY29sLCBzaW5jZSBpdCBpczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGxpa2VseSB0byBiZSB0ZWNobm9sb2d5IHNwZWNpZmljIGFuZCBjb3VsZCBiZSBkZWZpbmVk IGJ5IHRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJyb2FkYmFuZCBGb3J1bSwgQ2FibGVM YWJzIG9yIElFRUUgZGVwZW5kaW5nIG9uIHRoZSBkZXZpY2UuJm5ic3A7IFBvc3NpYmxlPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIGFyZSBTTk1QLCBORVRDT05GIG9yIChmb3Ig SG9tZSBHYXRld2F5cykgQ1BFIFdBTjxicj4mZ3Q7IE1hbmFnZW1lbnQ8YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBQcm90b2NvbCAoQ1dNUCkgZnJvbSB0aGUgQXV0byBDb25maWd1cmF0aW9uIFNl cnZlciAoQUNTKSAoYXM8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gVFIt MDY5KS48YnI+PGJyPkkgd29uZGVyIGlmIEkgY291bGQgcmUtc3VnZ2VzdCB3aGF0IEknZCBzYWlk IGVhcmxpZXIsIHRoYXQgbWF5YmUgdGhlIGRlZmluaXRpb24gb2YgTVAgaXM6PGJyPkEgZnVuY3Rp b24gdGhhdCBhc3Npc3RzIGEgTWVhc3VyZW1lbnQgQWdlbnQgd2l0aCBNZWFzdXJlbWVudCBUYXNr cy4gQWxsIG90aGVyIGludGVyZmFjZXMgdG8gYSBNUCBhcmUgdW5kZWZpbmVkLjxicj48YnI+QmFy YmFyYTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+bG1hcCBtYWlsaW5nIGxpc3Q8YnI+bG1hcEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA8YnI+PC9ib2R5Pg== ----_com.android.email_22470322809930-- From nobody Mon Mar 31 08:41:11 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D952C1A6F21; Mon, 31 Mar 2014 08:41:08 -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 VwyngPQiz4Z2; Mon, 31 Mar 2014 08:41:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E22831A0862; Mon, 31 Mar 2014 08:41:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331154104.9586.9034.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 08:41:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EkXxyeXDgKuxTKsJsAokm8KD4gk Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-04.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, 31 Mar 2014 15:41:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A framework for large-scale measurement platforms (LMAP) Authors : Philip Eardley Al Morton Marcelo Bagnulo Trevor Burbridge Paul Aitken Aamer Akhter Filename : draft-ietf-lmap-framework-04.txt Pages : 52 Date : 2014-03-31 Abstract: Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (large-scale measurement platforms). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lmap-framework-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-04 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 Mar 31 08:48:19 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7471A6F0B for ; Mon, 31 Mar 2014 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL0XtToE04Q6 for ; Mon, 31 Mar 2014 08:48:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id AD0E11A6F01 for ; Mon, 31 Mar 2014 08:48:12 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 31 Mar 2014 16:45:54 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.149]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 31 Mar 2014 16:45:05 +0100 From: To: Date: Mon, 31 Mar 2014 16:45:03 +0100 Thread-Topic: New Version Notification for draft-ietf-lmap-framework-04.txt Thread-Index: Ac9M96SrT9ch1Dy9RLWkPnyMnGdYkAAABTHg Message-ID: References: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> In-Reply-To: <20140331154106.9586.68779.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/VHrNYpoFfttvJvg73DBhrBGgdmI Subject: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-04.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: Mon, 31 Mar 2014 15:48:15 -0000 V2UndmUgY3JlYXRlZCBhIG5ldyB2ZXJzaW9uIC0wNCBvZiB0aGUgZnJhbWV3b3JrIGRvYy4gVGhp cyByZXNvbHZlcyAod2UgYmVsaWV2ZSkgYWxsIHRoZSBXRyBsYXN0IGNhbGwgaXNzdWVzIGFjY29y ZGluZyB0byB0aGUgY29uc2Vuc3VzIGFncmVlZCBpbiBMb25kb24uDQpUaGFua3MNClBoaWwgJiBm cmllbmRzDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxtYXAtZnJhbWV3 b3JrIA0KIA0KLS0NCkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBwaGlsaXAuZWFyZGxleUBidC5jb20NClNlbnQ6IDEzIE1hcmNoIDIwMTQgMTU6 MjkNClRvOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBbbG1hcF0gUHJvZ3Jlc3Mgb24gRnJhbWV3 b3JrDQoNCknigJltIHRyeWluZyB0byByZXNvbHZlIHRoZSBpc3N1ZXMgcmFpc2VkIGluIFdHIExh c3QgY2FsbCBhYm91dCB0aGUgZnJhbWV3b3JrIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDMgDQoNCjEuCUVzcGVjaWFsbHkgaWYgeW91IHdlcmVu 4oCZdCBpbiBMb25kb24sIHBsZWFzZSBjYW4geW91IGNoZWNrIHRoZSBzbGlkZXMgdG8gbWFrZSBz dXJlIHlvdeKAmXJlIGhhcHB5IHdpdGggdGhlIHByb3Bvc2VkIGNvbnNlbnN1cyBvbiB0aGUgdmFy aW91cyBpc3N1ZXMuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2VuZGEvODkvc2xpZGVzL3NsaWRl cy04OS1sbWFwLTIucGRmICAgIChpZ25vcmUgc2xpZGVzIDUsIDYsIDcg4oCTIHNlZSBsaW5rIGJl bG93IGluc3RlYWQpDQoyLglJIHByZXBhcmVkIHNvbWUgc2xpZGVzIGFib3V0IHRoZSBNQSB2cyBN UCB0ZXJtaW5vbG9neSBpbiBhY3Rpb24uIERvIHRoZXNlIGV4YW1wbGVzIGhlbHAgY2xhcmlmeSB0 aGluZ3M/IFRoZXkgY291bGQgYmUgdHVybmVkIGludG8gc29tZSB0ZXh0IGZvciB0aGUgbmV4dCB2 ZXJzaW9uIG9mIHRoZSBmcmFtZXdvcmsgIGh0dHA6Ly93d3cubGVvbmUtcHJvamVjdC5ldS9kcnVw YWwvc2l0ZXMvZGVmYXVsdC9maWxlcy9wdWJsaWNfZG93bmxvYWRzL2xtYXAtZnJhbWV3b3JrLWV4 YW1wbGVzLTEzbWFyY2gyMDE0LnBkZiAgDQoNCkkgcGxhbiB0byB3b3JrIG9uIHRoZSBmcmFtZXdv cmsgaS1kIG5leHQgd2Vlaywgc28gcGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBj b21tZW50cy4gDQoNCkJhY2tncm91bmQ6IEEgZ3JvdXAgb2YgdXMgbWV0IGZvciBhIHNpZGUgbWVl dGluZyBpbiBMb25kb24gYW5kICh3ZSB0aGluaykgcmVhY2hlZCBjb25zZW5zdXMgb24gYWxsIHRo ZSBvcGVuIGlzc3Vlcy4gSSBwcmVzZW50ZWQgdGhlIHByb3Bvc2FscyBkdXJpbmcgdGhlIFdHIG1l ZXRpbmcgaW4gTG9uZG9uLiBXZSBoYWQgc29tZSBnb29kIGRpc2N1c3Npb24sIGVzcGVjaWFsbHkg YWJvdXQgdGhlIHRlcm1pbm9sb2d5IGZvciBNZWFzdXJlbWVudCBQZWVyLCB3aGljaCBsZWQgdG8g Y29uc2Vuc3VzIHJvdW5kIGEgc2xpZ2h0bHkgcmV2aXNlZCB3b3JkaW5nLCBhbmQgdGhlIHN1Z2dl c3Rpb24gdGhhdCB0aGUgaS1kIHNob3VsZCBpbmNsdWRlIHNvbWUgZXhwbGFuYXRvcnkgZXhhbXBs ZXMsIHRvIGlsbHVzdHJhdGUgdGhlIE1BIHZzIE1QIHRlcm1pbm9sb2d5IGluIGFjdGlvbi4NCg0K VGhhbmtzIQ0KQmVzdCB3aXNoZXMNCnBoaWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiAzMSBNYXJjaCAyMDE0IDE2OjQxDQpUbzogQWFtZXIgQWtodGVyOyBB bCBDLiBNb3J0b247IEFsIE1vcnRvbjsgRWFyZGxleSxQTCxQaGlsaXAsVFVCOCBSOyBQYXVsIEFp dGtlbjsgUGF1bCBBaXRrZW47IE1hcmNlbG8gQmFnbnVsbzsgRWFyZGxleSxQTCxQaGlsaXAsVFVC OCBSOyBNYXJjZWxvIEJhZ251bG87IEJ1cmJyaWRnZSxULFRyZXZvcixUVUI4IFI7IEFhbWVyIEFr aHRlcjsgQnVyYnJpZGdlLFQsVHJldm9yLFRVQjggUg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA0LnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA0LnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQaGlsaXAgRWFyZGxleSBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29y aw0KUmV2aXNpb246CTA0DQpUaXRsZToJCUEgZnJhbWV3b3JrIGZvciBsYXJnZS1zY2FsZSBtZWFz dXJlbWVudCBwbGF0Zm9ybXMgKExNQVApDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAzLTMxDQpHcm91 cDoJCWxtYXANClBhZ2VzOgkJNTINClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA0LnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbG1h cC1mcmFtZXdvcmsvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNA0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDQNCg0KQWJz dHJhY3Q6DQogICBNZWFzdXJpbmcgYnJvYWRiYW5kIHNlcnZpY2Ugb24gYSBsYXJnZSBzY2FsZSBy ZXF1aXJlcyBhIGRlc2NyaXB0aW9uDQogICBvZiB0aGUgbG9naWNhbCBhcmNoaXRlY3R1cmUgYW5k IHN0YW5kYXJkaXNhdGlvbiBvZiB0aGUga2V5IHByb3RvY29scw0KICAgdGhhdCBjb29yZGluYXRl IGludGVyYWN0aW9ucyBiZXR3ZWVuIHRoZSBjb21wb25lbnRzLiAgVGhlIGRvY3VtZW50DQogICBw cmVzZW50cyBhbiBvdmVyYWxsIGZyYW1ld29yayBmb3IgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnRz LiAgSXQgYWxzbw0KICAgZGVmaW5lcyB0ZXJtaW5vbG9neSBmb3IgTE1BUCAobGFyZ2Utc2NhbGUg bWVhc3VyZW1lbnQgcGxhdGZvcm1zKS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg==