From nobody Sun Jun 1 02:42: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 E55E41A01C9; Sun, 1 Jun 2014 02:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 S41ipGurOOYL; Sun, 1 Jun 2014 02:42:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8311A01C6; Sun, 1 Jun 2014 02:42:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 069DBAC2; Sun, 1 Jun 2014 11:42:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lQ6V3fAO0vu2; Sun, 1 Jun 2014 11:42:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 1 Jun 2014 11:42:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4BB120017; Sun, 1 Jun 2014 11:42:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8InRbJFS9Psu; Sun, 1 Jun 2014 11:42:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B65420013; Sun, 1 Jun 2014 11:42:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2EB352D140C6; Sun, 1 Jun 2014 11:42:29 +0200 (CEST) Date: Sun, 1 Jun 2014 11:42:29 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140601094229.GA89541@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "STARK, BARBARA H" , "ippm@ietf.org" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E6113043E070@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140530225620.GA86358@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734EBC8BF@US70UWXCHMBA02.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734EBC8BF@US70UWXCHMBA02.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kMaQKcxCAPNgIFn3Mi0JsTFZ3WM Cc: "lmap@ietf.org" , "STARK, BARBARA H" , "ippm@ietf.org" Subject: Re: [lmap] UDP Echo example 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: Sun, 01 Jun 2014 09:42:43 -0000 Yes, I think this is what I wrote. /js On Sat, May 31, 2014 at 07:10:19PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > Wouldn't the selected interface for the UDP test instance be part of the options for the task. The options have the "parameters" for the test which is specific for each test, right? > > As for a MA telling the controller its capabilities - wouldn't it be part of the ma-interface-obj? > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, May 30, 2014 5:56 PM > To: STARK, BARBARA H > Cc: ippm@ietf.org; lmap@ietf.org > Subject: Re: [lmap] UDP Echo example > > On Fri, May 30, 2014 at 05:20:05PM +0000, STARK, BARBARA H wrote: > > > > If we look at the TR-069 data model in [TR-143], we see that MA1's UDP Echo server functionality has input parameters of (1) a port to listen on and (2) a source IP address (MA1 will only respond to UDP packets from this source IP address). In an LMAP world, I think these would be the information-model ma-task-options<0..*>. There is also an input of the network interface to listen on. [I see that while information-model lets the MA tell the Controller what its interfaces are, there's no current linkage to allow an interface to be specified for a ma-task-obj. I think this is probably just an oversight and needs to be added.] > > The interface is just another task option. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jun 1 23:52:30 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E271A019D for ; Sun, 1 Jun 2014 23:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 lQPnu1isPRNY for ; Sun, 1 Jun 2014 23:52:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67F81A00F2 for ; Sun, 1 Jun 2014 23:52:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9375273D for ; Mon, 2 Jun 2014 08:52:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BUYFAyTAbYmZ for ; Mon, 2 Jun 2014 08:52:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 08:52:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 712E320017 for ; Mon, 2 Jun 2014 08:52:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KnDxj0CXvhs7 for ; Mon, 2 Jun 2014 08:52:13 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id C36D620013 for ; Mon, 2 Jun 2014 08:52:13 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 08:52:12 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: review: draft-ietf-lmap-information-model-00 Thread-Index: AQHPfi8tfzUwLK/3oE6cKHZkmfP3Ug== Date: Mon, 2 Jun 2014 06:52:11 +0000 Message-ID: <74318B49-235B-4504-994E-10F63AAA8BC4@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_E821C0B0-D367-4947-9A80-C3512BCB586D"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/62Dwy6_8OQdvSXSs8XHCA5iR1A0 Cc: "Bajpai, Vaibhav" Subject: [lmap] review: draft-ietf-lmap-information-model-00 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, 02 Jun 2014 06:52:29 -0000 --Apple-Mail=_E821C0B0-D367-4947-9A80-C3512BCB586D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I made some notes while reading the information model document [1]. [1] http://tools.ietf.org/html/draft-ietf-lmap-information-model-00 Thought to share it along: Introduction ~~~~~~~~~~~~ The main components of a large-scale measurement platform are the Measurement Agents (hereafter MAs), the Controller(s) and the = Collector(s). The MAs are the elements actually performing the measurements. The = MAs are controlled by exactly one Controller at a time ... a) A (controller) target is part of the instruction channel object. The instruction channel object can be updated during the configuration. Can = it also be updated at any later point in time? I suppose through a separate instruction object. However, the instruction object currently only = refers to report channels. Pre-Configuration Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ object { ma-channel-obj ma-instruction-channel; ma-channel-obj ma-ma-to-controller-channel; [urn ma-device-id;] [uuid ma-agent-id;] } ma-preconfig-obj; a) MA needs a private key, should we add it here? b) MA needs a CA bundle to validate peer-certificates, should we add it = here? c) MA needs a certificate to interact over the channels. There is a certificate field within the channel object, but I suppose that = certificate refers to the remote endpoint. If it instead refers to the MA, then do = we want to allow the MA to authenticate using separate certificates over each = channel? d) Why do we use a URN namespace for a deviceID but not for a UUID? [rfc = 4122] e) The target is part of the channel object. Given, there are two = channels defined in the pre-configured object. A (misconfigured) MA can point to = two different controllers: controller1 (instruction channel) and controller2 (ma-to-controller channel). This may violate the assertion of a single controller interaction at a given point in time as described in the Sec = 1. f) Is the pre-configured object a singleton object? g) The device ID is optional. If the MA does not have a UUID = pre-configured, it needs to retrieve it via configuration. However, how will the = controller identify the MA if it does not supply a device ID? If the device ID is considered optional for privacy reasons, then should it also not be = optional in the status object where it is currently mandatory? Configuration Information ~~~~~~~~~~~~~~~~~~~~~~~~~ object { uuid ma-agent-id; ma-channel-obj ma-instruction-channel; [string ma-group-id;] [boolean ma-report-ma-id-flag;] [int ma-instruction-channel-failure-threshold;] } ma-config-obj; a) MA ID is a UUID, but group ID is a string. If we want to use a = string, shall we call it group name? b) The ma-to-controller channel object is missing in the configuration = object. If the controller can change the instruction channel, it should also be = able to change the ma-to-controller channel, no? Where the Measurement Group ID is set an additional flag (the Report = MA ID flag) is required to control whether the Measurement Agent ID is also = to be reported. c) The report MA ID flag is optional. However, does ^ text mean that the = flag becomes mandatory when the group ID is used. Then I suggest to describe = it as a tuple: object { uuid ma-agent-id; ma-channel-obj ma-instruction-channel; [(string,boolean) (ma-group-id, ma-report-ma-id-flag);] [boolean ma-report-ma-id-flag);] [int ma-instruction-channel-failure-threshold;] } ma-config-obj; Instruction Information ~~~~~~~~~~~~~~~~~~~~~~~ The nature and number of these Options will depend upon the = Measurement Task and will be defined in the Measurement Task Registry. Measurement Task Registry would be? perhaps a reference is missing here. object { string ma-task-name; urn ma-task-registry; string ma-task-options<0..*>; [string ma-task-cycle-id;] } ma-task-obj; a) =46rom this point in the document, the objects have a name. We didn't = have names for objects defined previously. Are these names meant to uniquely identify the instance? b) Would it be useful to have a version number associated with a task = object? There is a measurement version associated with a capability object. = Should we increase the granularity to have version numbers for each task object? object { string ma-schedule-task-name; ma-sched-report-obj ma-schedule-task-reports<0..*>; } ma-sched-task-obj; c) I assume ma-schedule-task-name is an identifer of this object. In = that case, we may be missing a reference to a task object as (below). object { string ma-schedule-task-name; ma-task-obj ma-task-obj<0..*>; ma-sched-report-obj ma-schedule-task-reports<0..*>; } ma-sched-task-obj; -- object { [int ma-schedule-task-filter;] // default: all string ma-schedule-task-report-channel-name; } ma-sched-report-obj; d) The ma-schedule-task-filter element is not described in the document. e) Previously we were embedding channel objects. Now we are referring to = them by name. Additionally 'report-channel' in the name gives an impression = that all schedules report back to the reporting channel (collector). However, = as mentioned in the document some schedules can also send results back to = the controller (via the ma-to-controller channel). I suggest to change this = object to as (below) object { [int ma-schedule-task-filter;] // default: all ma-channel-obj ma-schedule-channel-obj; } ma-sched-report-obj; -- object { boolean ma-suppression-enabled; [datetime ma-suppression-start;] // default: immediate [datetime ma-suppression-end;] // default: indefinite [string ma-suppression-task-names<0..*>;] // default: all tasks if // ma-suppression-task-names is empty [string ma-suppression-schedule-names<0..*>;] // default: all schedules if // ma-suppression-schedule-names is empty } ma-suppression-obj; f) Why do we use datetime objects to refer to start and end? Shall we = not just embed a timing-obj here? It's a nice reusable building block. Otherwise = we will also need to add more elements like the timezone offset here. MA to Controller Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ object { uuid ma-log-agent-id; datetime ma-log-event-time; code ma-log-code; string ma-log-description; } ma-log-obj; a) The purpose of ma-log-agent-id is not described in the document. b) For the datetime object (as previously reasoned) why don't we just = use a timing-obj, otherwise we also need the timezone offset information. c) Can we rename this section to "Logging Information"? The name "MA to Controller Information" gives an impression that in other sections the = MA does not send information to the controller, but that may not be true. For instance, the "Capability and Status Information" is also MA to = controller information. Capability and Status Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ object { uuid ma-agent-id; urn ma-device-id; string ma-hardware; string ma-firmware; string ma-software; ma-interface-obj ma-interfaces<0..*>; datetime ma-last-measurement; datetime ma-last-report; datetime ma-last-instruction; datetime ma-last-configuration; ma-capability-obj ma-supported-measurements<0..*>; } ma-status-obj; a) The ma-device-id and ma-agent-id are mandatory. If the controller = mandates a ma-group-id with a report-ma-id-flag as false, do we still report the ma-agent-id and ma-device-id in the status objects? b) The description of some fields is missing. For instance, it's unclear = what should be reported in ma-software. Is it the version of the OS running = on the MA? or is the version of the LMAP protocol? object { string ma-interface-name; string ma-interface-type; int ma-interface-speed; // mbps string ma-link-layer-address; ip-address ma-interface-ip-addresses<0..*>; [ip-address ma-interface-gateways<0..*>;] [ip-address ma-interface-dns-servers<0..*>;] } ma-interface-obj; a) Is the link-layer address reporting mandatory? object { urn ma-measurement-id; [string ma-measurement-version;] } ma-capability-obj; a) The ma-measurement-id and ma-measurement-version fields are not = described in the document. b) The ma-measurement-version I assume is to tag the version of tests = running the measurement? Would it not be useful to put this within the task-obj = to allow each test to have its own version? c) The status objects and capability objects are intermingled with one another. Shall we just factor these two out separately? For once, the capability information needs to be reported much earlier. The = instruction object can only be retrieved once the controller receives MA = capabilities. Secondly, capabilities are fairly static and may need to be less = frequently reported when compared to the status object. I suggest this refactor = (below) -- this can be introduced as a separate section between 3.3 and 3.4. object { uuid ma-agent-id; urn ma-device-id; string ma-hardware; string ma-firmware; string ma-software; ma-interface-obj ma-interfaces<0..*>; ma-task-obj ma-task-obj<0..*>; // supported measurement = tasks } ma-capability-obj; -- this can remain here as section 3.6 object { datetime ma-last-measurement; datetime ma-last-report; datetime ma-last-instruction; datetime ma-last-configuration; } ma-status-obj; Reporting Information ~~~~~~~~~~~~~~~~~~~~~ object { datetime ma-report-date; [uuid ma-report-agent-id;] [string ma-report-group-id;] ma-context-obj ma-report-context<0..*>; ma-report-task-obj ma-report-tasks<0..*>; } ma-report-obj; a) Shall we just use a timing-obj? Otherwise we also need a timezone = offset field here. b) Why is groupID a string but agentID is a UUID? There is a description = in 3.3 how groupID could be a name, then shall we not call it group name? object { ma-task-obj ma-report-task-config; string ma-report-task-column-headers<0..*>; ma-result-row-obj ma-report-task-rows<0..*>; } ma-report-task-obj; object { datetime ma-report-result-time; [int ma-report-result-cross-traffic;] data ma-report-result-values<0..*>; } ma-result-row-obj; a) Shall we just use a timing-obj? Otherwise we also need a timezone = offset field here. b) The description of ma-report-result-cross-traffic field is missing. c) Isn't "data" very generic? Shall we call it a blob/clob? Channels ~~~~~~~~ The certificate can be the digital certificate associated to the FQDN in the URL or it can be the certificate of the Certification Authority that was used to issue the certificate for the FQDN (Fully Qualified Domain Name) of the target URL (which will be retrieved later on using a communication protocol such as SSL). a) /s/SSL/TLS? As with the Measurement task Configuration, each Channel is also given = a local short name by which it can be referenced from a Measurement = Schedule or other elements. a) Are names uniquely identifying the objects? In order to reference a = object from another, sometimes we embed it but sometimes we reference it by a = name. Can we please make this consistent? As for Measurement Tasks, multiple interfaces are also supported. For example the Controller could choose to receive some results over GPRS. = This is especially useful when such results indicate the loss of = connectivity on a different network interface. Facility is also provided for the = Controller to choose whether to receive empty reports where there is no Measurement = Task information. In some cases this may be desirable to monitor the = health of the measurement system. a) The text gives an impression that the controller receives the = reports. I think we mean that the controller chooses what reports are sent to the collector, but it's currently confusing to read. object { string ma-channel-name; url ma-channel-target; certificate ma-channel-certificate; ma-timing-obj ma-channel-timing; [string ma-channel-interface-name;] [boolean ma-channel-connect-always;] // default: false // (only connect when data is pending) } ma-channel-obj; a) The certificate refers to the certificate of the MA or the remote = endpoint (controller/collector)? There are two peer certificates exchanged on the channel, shall we not have two separate fields? b) Does "certificate" mean an X.509 certificate? c) It would be nice to have a description on "ma-channel-connect-always" field? Is this field meant to allow persistent connections? Timing Information ~~~~~~~~~~~~~~~~~~ object { [string ma-timing-name;] union { ma-periodic-obj ma-timing-periodic; ma-calendar-obj ma-timing-calendar; ma-one-off-obj ma-timing-one-off; ma-immediate-obj ma-timing-immediate; } [ma-randomness-obj ma-timing-randomness;] } ma-timing-obj; a) The ma-timing-name is optional here. Should we not use it to uniquely identify this object? object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-weekdays<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; a) The timezone-offset field should be part of the generic timing-obj, = no? b) Do we also need a field to determine if daylight saving time is in = effect? c) The definition of weekdays may get confusing. Would it better to = rename ma-calendar-weekdays to ma-calendar-days? Notation ~~~~~~~~ An optional field is enclosed by [ ], and an array is indicated by two numbers in angle brackets, >, where m indicates the minimal = number of values, and n is the maximum. The symbol * for n means no upper = bound. a) Most of the IM elements use <0..*> notation. What would be the = difference between an empty array <0> and an optional field using []? b) It would also be nice to know how to uniquely identify an IM object. Perhaps introducing the notation of underlining an item (or a set of = items) that can uniquely identify the instance. Organizational Changes ~~~~~~~~~~~~~~~~~~~~~~ a) How about starting out section 3 with a subsection on building blocks = such as : a) Timing objects and b) Channels. The other subsections may become easier to read once these ideas are wired in the brain. b) An enumerated description of what each field in each IM element means = would be nice. It is also not clear why some fields are chosen to be optional against others. Editorial Changes ~~~~~~~~~~~~~~~~~ /s/To from agreement/To form agreement Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com --Apple-Mail=_E821C0B0-D367-4947-9A80-C3512BCB586D 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 iQEcBAEBCgAGBQJTjB8aAAoJEHR3XKwTWKOZClEH/AwuEaAvrB9tO/0Wykm9Dw5A xhSBYk9ryTk03bwVj4q/Lie0/U8SJx2rz8Lq5TuBFOl3rL93FAPC5mzYhujWusM3 suZ4EJGjgJ0zJ4PcpSQuDBKZbAYDk/Ahgdeu/uS2Js3q5ivuYPbVOEa9SMp7/T0C MTSa+U45tMwsTEGhxtaSP2JJt+EvlEEpfYnc6dBgkRISzSNh00dDSj5YLeWIkhTo Yd2C0GsQVvsLKrCbwli5GxEpDrLCa2BSxHPg1JkDmC6YhtFosvAcV+VBtfH25Q0Y 0I4VN7RWpjISbTwxL1SBbNVLZXl/1U8FbCFtZOI2xRFIVZnZg/EU/81atw34hKU= =x1/n -----END PGP SIGNATURE----- --Apple-Mail=_E821C0B0-D367-4947-9A80-C3512BCB586D-- From nobody Mon Jun 2 08:09: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 84A0A1A021F for ; Mon, 2 Jun 2014 08:09:57 -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 KEYPSaU-teXF for ; Mon, 2 Jun 2014 08:09:53 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FF51A0141 for ; Mon, 2 Jun 2014 08:09:50 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 2 Jun 2014 16:09:42 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 2 Jun 2014 16:09:44 +0100 From: To: Date: Mon, 2 Jun 2014 16:09:41 +0100 Thread-Topic: Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+c1IuW/beYBhwTt+OiwOS2H6N3A== 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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4A8D457EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/G8uO8dvCdF5Bm5x-h5N85BI5ePg Subject: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 02 Jun 2014 15:09:57 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4A8D457EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following up on the thread (after holidays) current definitions:- Passive Measurement Method (Task): A Measurement Method (Task) in which a M= easurement Agent observes existing traffic but does not inject Active Measu= rement Traffic. Active Measurement Task: A Measurement Task in which a Measurement Agent cr= eates or receives Active Measurement Traffic, by coordinating with one or m= ore other Measurement Agents or Measurement Peers using protocols outside t= he initial LMAP work scope. -- My view is that the Task is about what the MA does. To answer Barbara's qui= z question, it is possible to define the activity as two small Tasks or one= larger integrated Task. I can understand the desire to talk 'holistically' about the whole measurem= ent system. But looking at say Fig A4 in http://tools.ietf.org/html/draft-i= etf-lmap-framework-05#section-10 The passive monitor is an MA running Passi= ve Task. It observes existing traffic from entities that are, from its pers= pective, MPs. This traffic could be user traffic or actually generated by a= nother (Active) Task. As far as the function labelled Passive Monitor is co= ncerned, it doesn't care. I thought Barbara's example of UDP echo makes the good point that the clien= t and server ends have a different role so may well have to point to differ= ent registry entries. I agree with Al that passive and active are two end points of a continuum a= nd there are techniques in-between the extremes (like Nalini's colour marki= ng of pkts). I'd prefer to leave it to ippm to work on the subtleties - as = far as lmap is concerned we know that there's a registry of tests, which ip= pm is proposing to sub-divide into active and passive. Maybe later ippm wil= l decide which sub-registry in-between tests should be in, or that a new re= gistry is needed, or whatever. I think lmap can live with this slight uncer= tainty. So I think it's better for the definition of Passive to stick with "observe= s". Greg didn't like the formulation "Active Measurement Method (Task)" - if I = remember, he thought it was unclear and wanted it split into two definition= s. Since we already have definitions for Measurement Method and Measurement= Task, I actually think it's unnecessary to distinguish Method & Task in th= e Passive & Active definitions. So I suggest deleting the 'Active Measureme= nt Method' definition, and similarly making the Passive definition just abo= ut 'Passive Measurement Task'. Greg also didn't like the way the Active definition talks about coordinatio= n. I think the point is: whilst some Active Tasks involve the MA coordinati= ng with other MPs (examples A1 and A2 in the Appendix - eg web server respo= nds to client request), in others (example A3) the Controller controls the = other MA and the first MA just sends it traffic (the MAs don't really coord= inate with each other). -- Proposal:- In the Intro, add to the paragraph about Active & Passive Tasks: There may also be Measurement Tasks that are intermediate between Passive a= nd Active ones; consideration is outside the initial LMAP work scope. In terminology, tweak the definitions:- Passive Measurement Task: A Measurement Task in which a Measurement Agent o= bserves existing traffic but does not inject Active Measurement Traffic. Active Measurement Task: A Measurement Task in which a Measurement Agent se= nds Active Measurement Traffic to, or receives it from, one or more other M= easurement Agents or Measurement Peers, and perhaps coordinates with them u= sing protocols outside the initial LMAP work scope. Best wishes phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4A8D457EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following up = on the thread (after holidays)

&= nbsp;

current definitions:-

=

Passive Measurement Method (Task): A Measurement Me= thod (Task) in which a Measurement Agent observes existing traffic but does= not inject Active Measurement Traffic.

 

Active Measurement Task: A = Measurement Task in which a Measurement Agent creates or receives Active Me= asurement Traffic, by coordinating with one or more other Measurement Agent= s or Measurement Peers using protocols outside the initial LMAP work scope.=

 

--

My view is that the Task = is about what the MA does. To answer Barbara’s quiz question, it is p= ossible to define the activity as two small Tasks or one larger integrated = Task.

 

I can understand the desire to talk ‘holisticallyR= 17; about the whole measurement system. But looking at say Fig A4 in ht= tp://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The pa= ssive monitor is an MA running Passive Task. It observes existing traffic f= rom entities that are, from its perspective, MPs. This traffic could be use= r traffic or actually generated by another (Active) Task. As far as the fun= ction labelled Passive Monitor is concerned, it doesn’t care.

 

I thought Barbara’s example of UDP echo makes the good point that t= he client and server ends have a different role so may well have to point t= o different registry entries.

&n= bsp;

I agree with Al that passive and acti= ve are two end points of a continuum and there are techniques in-between th= e extremes (like Nalini’s colour marking of pkts). I’d prefer t= o leave it to ippm to work on the subtleties – as far as lmap is conc= erned we know that there’s a registry of tests, which ippm is proposi= ng to sub-divide into active and passive. Maybe later ippm will decide whic= h sub-registry in-between tests should be in, or that a new registry is nee= ded, or whatever. I think lmap can live with this slight uncertainty.<= /o:p>

So I think it’s better for the defin= ition of Passive to stick with “observes”.

 

 <= /o:p>

Greg didn’t like the formulation = 220;Active Measurement Method (Task)” – if I remember, he thoug= ht it was unclear and wanted it split into two definitions. Since we alread= y have definitions for Measurement Method and Measurement Task, I actually = think it’s unnecessary to distinguish Method & Task in the Passiv= e & Active definitions. So I suggest deleting the ‘Active Measure= ment Method’ definition, and similarly making the Passive definition = just about ‘Passive Measurement Task’.

 

Greg also didn= ’t like the way the Active definition talks about coordination. I thi= nk the point is: whilst some Active Tasks involve the MA coordinating with = other MPs (examples A1 and A2 in the Appendix – eg web server respond= s to client request), in others (example A3) the Controller controls the ot= her MA and the first MA just sends it traffic (the MAs don’t really c= oordinate with each other).  

 

--

 

Proposal:-=

In the Intro, add to the paragraph about Active= & Passive Tasks:

There may also = be Measurement Tasks that are intermediate between Passive and Active ones;= consideration is outside the initial LMAP work scope.

 

In terminolo= gy, tweak the definitions:-

Passive M= easurement Task: A Measurement Task in which a Measurement Agent observes e= xisting traffic but does not inject Active Measurement Traffic.<= /p>

 

Act= ive Measurement Task: A Measurement Task in which a Measurement Agent sends= Active Measurement Traffic to, or receives it from, one or more other Meas= urement Agents or Measurement Peers, and perhaps coordinates with them usin= g protocols outside the initial LMAP work scope.

 

 <= /p>

Best wishes

phil

 

 

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4A8D457EMV67UKRDdoma_-- From nobody Mon Jun 2 08:23: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 E4A8D1A024A for ; Mon, 2 Jun 2014 08:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 d1X92M3vLo1Z for ; Mon, 2 Jun 2014 08:22:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF031A0141 for ; Mon, 2 Jun 2014 08:22:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E19A4F6D; Mon, 2 Jun 2014 17:22:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Et73c0kz_WmD; Mon, 2 Jun 2014 17:22:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 Jun 2014 17:22:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6839420017; Mon, 2 Jun 2014 17:22:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hp9XzeSFBJUA; Mon, 2 Jun 2014 17:22:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA8F520013; Mon, 2 Jun 2014 17:22:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1EBAE2D15B0C; Mon, 2 Jun 2014 17:22:49 +0200 (CEST) Date: Mon, 2 Jun 2014 17:22:49 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20140602152249.GA16074@elstar.local> Mail-Followup-To: 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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/OHYnK3GeFCwct5CEaSHz8EbTOLc Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:23:07 -0000 On Mon, Jun 02, 2014 at 04:09:41PM +0100, philip.eardley@bt.com wrote: > > Proposal:- > > In the Intro, add to the paragraph about Active & Passive Tasks: > > There may also be Measurement Tasks that are intermediate between Passive and Active ones; consideration is outside the initial LMAP work scope. > > > > In terminology, tweak the definitions:- > > Passive Measurement Task: A Measurement Task in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic. > > > > Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordinates with them using protocols outside the initial LMAP work scope. > And do we remove '(active|passive) measurement method' and do we try to get rid nof 'measurement method' altogether (so that IPPM can define and use this term in a way they find it most useful)? /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 Mon Jun 2 08:32: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 B11D51A0241 for ; Mon, 2 Jun 2014 08:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 t8r0G2trrxna for ; Mon, 2 Jun 2014 08:32:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4364E1A022A for ; Mon, 2 Jun 2014 08:32:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2849E7B for ; Mon, 2 Jun 2014 17:32:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rD48XLh0Y9GR for ; Mon, 2 Jun 2014 17:32:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 17:32:17 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05C6520017 for ; Mon, 2 Jun 2014 17:32:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N5rzXm-iuot5 for ; Mon, 2 Jun 2014 17:32:15 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4827220013 for ; Mon, 2 Jun 2014 17:32:15 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 17:32:15 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: review: draft-bagnulo-lmap-http-01 Thread-Index: AQHPfnfUVxqGYiiiyU+0RkuqmF7GUQ== Date: Mon, 2 Jun 2014 15:32:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_9B55E3A5-9BC8-4BAD-8EA5-7E19196E7263"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/72qh_nQCKWFr5OFVSrzLMdIdoZY Cc: "Bajpai, Vaibhav" Subject: [lmap] review: draft-bagnulo-lmap-http-01 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, 02 Jun 2014 15:32:30 -0000 --Apple-Mail=_9B55E3A5-9BC8-4BAD-8EA5-7E19196E7263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I read the LMAP HTTP protocol document [1] and made some notes. [1] http://tools.ietf.org/html/draft-bagnulo-lmap-http-01 Here is my proposal on how to take this work forward: Overview ~~~~~~~~ Once that the MA is deployed it will perform the following = operations: o After the MA is deployed, it will obtain Instructions from one of the pre-configured Controllers. These Instructions include information about the set of measurements to be performed, a schedule for the execution of the measurements as well as a set of report channels. This information is downloaded by the MA from the Controller. The MA will periodically check whether there are new Instructions available from the Controller. This document specifies how the MA uses the HTTP protocol to retrieve information from the Controller. According to the information model = [draft-ietf-lmap-information-model-00]. Before ^, MA also needs to: a) Contact the initial controller to retrieve configuration information. I personally think it also must send capabilities before asking for instructions. The controller will bake instructions depending on the = received MA capabilities: b) Send MA capabilities over the MA-to-controller channel. I can provide a writeup for a) and b) if need be. o The MA will execute measurements either by passively listening to traffic or by actively sending and receiving measurement packets. How this is done is out of the scope of this document. o After one or more measurements have been performed, the MA reports the results to the Collector. The timing of these uploads is specified in the measurement Instruction i.e. each measurement specified in a measurement Instruction contains a report information, defining when the MA should report the results back to the Collector. This document specifies how the MA uses the HTTP protocol to upload the measurement results to the Collector. o In addition, the MA will periodically report back to the Controller information about its capabilities (like the number of interfaces it has, the corresponding IP addresses, the set of measurement methods it supports, etc) and also logging information (whether some of the requested measurement tasks failed and related information). According to the information model = [draft-ietf-lmap-information-model-00]: c) The MA also executes task objects that perform logging and status reporting. These task objects instead send the results over the MA-to-controller channel. Perhaps, we should merge ^ bullets to state = that the schedule is agnostic to what kind of task is being run. Information Model ~~~~~~~~~~~~~~~~~ The control information (or Instruction) has the following five = elements: o The Agent Information element. This contains pointers (URLs) to the other 4 elements which contain the actual control information. This serves as a level of indirection allowing the MA to have a root element from which retrieve all the other elements. a) This ^ is the instruction object as per the information model [draft-ietf-lmap-information-model-00]. Shall we replace "Agent = Information" with "Instruction Information"? o The Set of Measurement Task Configurations: This element defines the measurements/test that the MA will perform without defining the schedule when they will be performed. o The Set of Report Channels: This element defines the set of collectors as well as the reporting schedules for the reports. b) The MA also performs logging and status reporting that goes over the MA-to-controller channel. Perhaps we should replace "report channels" = with "channels" to make this generic that covers all aspects. I also raised = this issue in the information model document = [draft-ietf-lmap-information-model-00]. o The Set of Measurement Schedules for Repeated Tasks: defines the schedules for the repeated measurements, by referencing the measurement tasks defined in the second element. o The Set of Measurement Schedules for Isolated Tasks: defines the schedules for isolated measurements, again by referencing the measurement tasks defined in the second element. c) The information model [draft-ietf-lmap-information-model-00] does not distinguish between schedules of isolated and repeated tasks. Perhaps we should merge these 2 bulleted items and call them measurement schedules? d) We are missing discussion on supression object. Summary of Report information model here. Summary of Status information model here. e) This is referred as "capability and status information" in the = information model [draft-ietf-lmap-information-model-00]. Summary of Logging information model here. f) This is referred as "MA-to-controller" information in the information = model [draft-ietf-lmap-information-model-00]. I personally think we should = rename the information model section name to logging. Summary of Configuration information model here. g) This should be discussed before the instruction information model. h) We are also missing discussion on pre-configuration information. Example ~~~~~~~ Once the MA is deployed, it uses the POST method to retrieve the Agent Information element of the Instruction from the controller as follows POST /.well-known/lmap/ma-info/ HTTP/1.1 Host: controller.example.com Content-Type: application/lmap-maid+json Accept: application/lmap-config+json { "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479", } a) Within the information model [draft-ietf-lmap-information-model-00], = this is a request to fetch the instruction object. I think we should replace references to "agent information" with "instruction object". = Additionally, the POST request must be made to the instruction channel target. I think the .well-known mechanism is only used for registration with the initial controller. As per the information model [draft-ietf-lmap-information-model-00], = before retrieving the instruction object as ^, the MA must do these things: b1) Register and retrieve the configuration information (MA ID, = instruction channel, and MA-to-controller channel) by sending a POST request with = its device ID to the intial controller embedded in the pre-configured = instruction channel. We are missing this example. b2) This registration mechanism must also be idempotent. I personally also think, that the MA should send its capabilities before retrieving the instruction object: c) Send MA capabilities over the configured MA-to-controller channel to = the controller. The controller will use this information to prepare an = instruction object to be sent to the MA on further request. We are missing this = example. For this particular example, the Agent information returned looks like = this: { "ma-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "version": "1.0", "measurement-set": "http://controller.example.org /measurements/", "report-channel-set": "http://controller.example.org /channels/", "repeated-schedule-set": "http://controller.example.org /schedules/" "status-set": "http://controller.example.org /status/" "logging-set": "http://controller.example.org /logging/" } According to the information model = [draft-ietf-lmap-information-model-00]: a) "measurement-set" should be "ma-tasks" b) "report-channel-set" should be "ma-report-channels" (I personally = think this should be ma-channels) c) "repeated-schedule-set" should be "ma-schedules" d) "status-set" and "logging-set" are part of a) and should be removed. = The MA-to-controller channel used to send these objects is sent during configuration. e) We are missing a pointer to "ma-suppression" The first thing that the MA does is to send its status information to the Controller. this contains information about the MA capabilities and local configuration, such as interfaces' information and supported measurement task. For this particular example, the MA would execute the following method: a) I think we should decouple status and capability reporting. = Capabilities are fairly static while status objects need to be periodically reported. = I also raised this issue in the information model review [draft-ietf-lmap-information-model-00]. POST /.well-known/lmap/ma-info/ HTTP/1.1 Host: controller.example.com Content-Type: application/lmap-maid+json Accept: application/lmap-config+json { "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479", "ma-interfaces: [ {"if-name" : eth0 "if-type" : ethernetCsmacd "ip-adddress" :{ "protocol": v4 "address": 10.1.1.1 } }] "supported-measurements":[ {"metric": UDP_Latency}] } b) The ^ example is only sending capabilities. We need an example on how = to send status objects. c) Shouldn't we use a target specified in the MA-to-controller channel = to send capability and status information? The ^ example is sending a POST to a generic .well-known location. d) "supported-measurements" according to the information model [draft-ietf-lmap-information-model-00] is "ma-tasks" The MA will next retrieve the set of Instructions from the Controller. The POST for the Instructions will result in the following information: /s/Instructions/Tasks Transport protocol ~~~~~~~~~~~~~~~~~~ 6.1. Pre-configured information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o The UUID for the MA. This should be pre-configured so that the Controller is aware of the MA and can feed configuration information and measurement Instructions to it. a) The information model [draft-ietf-lmap-information-model-00] keeps = this open. The MA UUID can either be pre-configured or provided by the = initial controller during the configuration setup when MA registers a device ID. Trevor and I discussed this previously, and I think Trevor was hinting = towards preferring the latter approach. I also prefer retrieving UUID from the controller. 6.2. Control Protocol ~~~~~~~~~~~~~~~~~~~~~~ The MA uses the Control protocol to retrieve all the resources = described above, namely, the Agent information, the Set of Measurement Task Configurations, the Set of Report Channels, the Set of Measurement = Schedules for Repeated Tasks and the Set of Measurement Schedules for Isolated = Tasks. a) The information model [draft-ietf-lmap-information-model-00] does not = make a separation between schedules for repeated tasks and isolated tasks. It = just proposes to use a timing-obj that eventually decides the behavior of the schedule. I think we should merge ^ definitions. 6.2.1.1. Using the GET method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The frequency for the periodical retrieval is contained in the Agent Information (???). Agent Information retrieval: In order to retrieve the Agent information the MA uses the HTTP GET method follows: GET /.well-known/lmap/ma-info/ < ma-iid> HTTP/1.1 Host: FQDN or IP of the Controller Accept: application/json (as per [RFC4627]) The Agent Information should contain the Configuration Retrieval Schedule (i.e. how often the MA should retrieve configuration information) and also the Measurement Instruction Retrieval Schedule (i.e. how often the MA should retrieve the Measurement Instruction from the Controller). COMMENT: this is missing from the Data Model a) The term "Agent Information" is not defined in the information model [draft-ietf-lmap-information-model-00]. b) According to the information model = [draft-ietf-lmap-information-model-00], the schedules however are sent as part of the instruction object = retrieval. c) I think RFC 4627 has been recently obsoleted by RFC 7159. 6.2.2. Handling communication failures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o The MA will use a timeout for the communication of TIMEOUT seconds. The value of TIMEOUT MUST be configurable via the aforementioned Configuration Information retrieval protocol. The default value for the TIMEOUT is 3 seconds. If after the timeout, the communication with the Controller has not been established, the MA will retry doing an exponential backoff and doing a round robin between the different Controllers it has available. a) In the information model [draft-ietf-lmap-information-model-00], the instruction channel allows only 1 controller target. The idea of doing a round-robin between available controllers on ocassions of TIMEOUT may = save the MA at multiple occassions. Shall we use this concept in the information = model by changing the target to an array? 6.3.1. Handling communication failures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If the MA is uploading the report to several Collectors and it manages to establish the communication before TIMEOUT seconds with at least one of them, but not with one or more of the other Collectors, then the MA gives up after TIMEOUT seconds and it MAY issue an alarm. The definition of how to do that operation is out of the scope of this document. a) What should the MA do when it has results to upload, but cannot = contact any collector? The schedule is running and constantly increasing the size of = the results as the time goes by. When should it decide to drop all collected results to make sure it doesn't go out of space? Editorial Changes ~~~~~~~~~~~~~~~~~ The reader is referred to the terminology draft for further details. a) The terminology draft is merged with the framework draft, no? b) [I-D.ietf-lmap-framework] is obsolete [I-D.burbridge-lmap-information-model] is obsolete. [I-D.bagnulo-ippm-new-registry-independent] is obsolete. o Measurement protocols: These are the protocols used between the MA and the Measurement Peer in active measurements. These are the actual packets being used for the measurement operations. c) The "measurement protocol" term is not defined in the framework = document. ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com --Apple-Mail=_9B55E3A5-9BC8-4BAD-8EA5-7E19196E7263 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 iQEcBAEBCgAGBQJTjJj9AAoJEHR3XKwTWKOZ0/QH/iBBTHU/5ktMZBbNn7UiZiPU sn15jIHPvha1uLB+X1yatj98OXsp27HCAXx1ZnRmNCue1c1Wczu+REfmQkik1sco bWrlWI2D1p9oB15UkD+X/NHfnblBzK59ts2zWM+fB62g7pOylRzdIEgtanE7ocnX EqvidjTBVdjZ50kIlhkYbfectda3Xh+OAvZMocAccPSsI5AME2i26XR2p5QVs5r2 tU1Vq4CsVCs3sgK5g4iR/wWUsEkA8SUXPmXrcRy0N32oLZ88iAXmOXazRacIo5wo aq7K06RN1qmVqokRp184QCDkRdsp98LzRm+dXIOabQGuxDAVOh+vBMpQ5sOmegs= =siC+ -----END PGP SIGNATURE----- --Apple-Mail=_9B55E3A5-9BC8-4BAD-8EA5-7E19196E7263-- From nobody Mon Jun 2 09:02: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 2203A1A035E for ; Mon, 2 Jun 2014 09:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 11P_kHRx_NXF for ; Mon, 2 Jun 2014 09:02:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA081A0256 for ; Mon, 2 Jun 2014 09:02:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 797EA78A for ; Mon, 2 Jun 2014 18:02:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Df6YKb9Z0WfC for ; Mon, 2 Jun 2014 18:02:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 2 Jun 2014 18:02:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29F0220017 for ; Mon, 2 Jun 2014 18:02:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PCTl39PkV2o7 for ; Mon, 2 Jun 2014 18:02:29 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7FEF120013 for ; Mon, 2 Jun 2014 18:02:29 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 18:02:29 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: review: draft-ietf-lmap-framework-05 Thread-Index: AQHPfnwNCedbmN+Pn0meBiGW4vGlsQ== Date: Mon, 2 Jun 2014 16:02:28 +0000 Message-ID: <347A1B15-6EC0-47B1-A4B8-AE9D161B6D77@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_82405F39-63F4-44CC-8C23-B32FC019DD43"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/bkqN6YnjRAyK7gn7Nyrr9KYD224 Cc: "Bajpai, Vaibhav" Subject: [lmap] review: draft-ietf-lmap-framework-05 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, 02 Jun 2014 16:02:41 -0000 --Apple-Mail=_82405F39-63F4-44CC-8C23-B32FC019DD43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I read the LMAP framework document [1] and made some notes: [1] http://tools.ietf.org/html/draft-ietf-lmap-framework-05 Thought to share it along: Items beyond the scope of the initial LMAP work ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2. It does not define interactions between the Collector and Controller. It is quite likely that there will be such interactions, optionally intermediated by the data analysis tools. For example, if there is an "interesting" Measurement Result then the measurement system may want to trigger extra Measurement Tasks that explore the potential cause in more detail; or if the Collector unexpectedly does not hear from a MA, then the measurement system may want to trigger the Controller to send a fresh Instruction Message to the MA. I thought about some situations where the collector may want to (out of = band) verify that the MA did talk to the controller. This is *out of scope* of = LMAP as aforementioned. Since some such examples are already mentioned in the ^ = writeup.=20 Here is some additional input for this bulleted item: a) A misbehaving MA sending arbitrary results to the collector: In such = a situation an MA may decide to not honour the controller instruction and = post random results to the collector. The organization responsible for the measurement system may want to somehow verify at the collector end = whether the results correlate to the schedule pushed to the MA. b) A mischievous MA can decide to go through the MA-controller = interactions described in the framework, but later delegate the task of running measurements and reporting results to a proxy MA. The proxy MA then = pushes the results to the collector. The organization responsible for the = measurement system may somehow want to verify at the collector end that the results = are sent by the same MA entity to which the instructions were pushed to. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com --Apple-Mail=_82405F39-63F4-44CC-8C23-B32FC019DD43 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 iQEcBAEBCgAGBQJTjKAUAAoJEHR3XKwTWKOZZO4H/3VWG+VSMdJsdrRzsUUTJ9nH FD9iOYVLrxujM2014Mw90gx1XruLWc4NDqY19PFxzBrzqR0EcHLEb0SvmIsZ/wAa ShsBKc3aesbzSPqno9yxymiEdWNiFCF76IVDA+V05C7O7JpFloRwtlZ3Fypa7gIx TEyjG+cImvUxyxStY+cHyhnf7vP/giMJH33EWE3XFmfOgKDW7tCfc6l/26YpTI67 Tne2qaRRaFdMTxVPRRo0JsPE4U+9Y3rryYH7HfqprWqXrwkDcHtEGckg/REPT0+s ZP0dN4Xk5xAT4gqOLRKERz/cWnsTP9Q/qV0uBVM2KvnvMnDsfGGVsvQqAuKkKso= =GE2F -----END PGP SIGNATURE----- --Apple-Mail=_82405F39-63F4-44CC-8C23-B32FC019DD43-- From nobody Mon Jun 2 10:04: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 0E5D31A0241 for ; Mon, 2 Jun 2014 10:04:11 -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 pzGLsXWjiKUY for ; Mon, 2 Jun 2014 10:04:09 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A571A023A for ; Mon, 2 Jun 2014 10:04:09 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so5530334veb.17 for ; Mon, 02 Jun 2014 10:04: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 :content-type; bh=fDd2E0yJfuRo7kqIeAC8Y0cIqvaMEuVO+mzTTscFldk=; b=cSThOXsLXoMlMYCaQhD4379xg12Ta8qSBlNXH4/WBrtYQsyn8/s1dpN/Hb+OL6muEw ChPF/HhpUnzMzX5uL+jEdVxJXqHa+x4GQFq+4twGWiUEJoCP7Y2pQVyOOuxxWlgI73uc 9xUCIDMpfq8MFbxbB/lCHo8vYY5FRY8Ss/p6pdUpH74Y0DsWtOsU6NYiHgSQOcFnKQS1 mEXZynX4UdLZKmaGX5ZoAcVUnxdh2Qf2WGnvcm8W2hm5mbIyQKBKHJQGjn2OljlBCPLq zxhmHHOjMfXe67qn9SUBj1EOF5lynEBAiDTtJx45SDfUsJwLxzy6RtQrKRG+IqHuBNDB 96kQ== MIME-Version: 1.0 X-Received: by 10.52.138.232 with SMTP id qt8mr2442765vdb.44.1401728643556; Mon, 02 Jun 2014 10:04:03 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Mon, 2 Jun 2014 10:04:03 -0700 (PDT) In-Reply-To: <20140602152249.GA16074@elstar.local> References: <20140602152249.GA16074@elstar.local> Date: Mon, 2 Jun 2014 10:04:03 -0700 Message-ID: From: Greg Mirsky To: Juergen Schoenwaelder , "philip.eardley@bt.com" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=bcaec52d5683deeb7a04fadd61ed Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/H72BAkUZfkQ0tUf7bnkVNfnt94k Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 02 Jun 2014 17:04:11 -0000 --bcaec52d5683deeb7a04fadd61ed Content-Type: text/plain; charset=UTF-8 Hi Juergen, I think that LMAP Framework may not need to define what Measurement Method is and leave it to IPPM, perhaps in its Performance Registry work, to define. But I believe that the LMAP Framework will have to use the Measurement Method and then reference the definition given by IPPM. That may cause document dependency and delay progress of the LMAP Framework. Regards, Greg On Mon, Jun 2, 2014 at 8:22 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jun 02, 2014 at 04:09:41PM +0100, philip.eardley@bt.com wrote: > > > > > Proposal:- > > > > In the Intro, add to the paragraph about Active & Passive Tasks: > > > > There may also be Measurement Tasks that are intermediate between > Passive and Active ones; consideration is outside the initial LMAP work > scope. > > > > > > > > In terminology, tweak the definitions:- > > > > Passive Measurement Task: A Measurement Task in which a Measurement > Agent observes existing traffic but does not inject Active Measurement > Traffic. > > > > > > > > Active Measurement Task: A Measurement Task in which a Measurement Agent > sends Active Measurement Traffic to, or receives it from, one or more other > Measurement Agents or Measurement Peers, and perhaps coordinates with them > using protocols outside the initial LMAP work scope. > > > > And do we remove '(active|passive) measurement method' and do we try > to get rid nof 'measurement method' altogether (so that IPPM can > define and use this term in a way they find it most useful)? > > /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 > --bcaec52d5683deeb7a04fadd61ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,
I think that LMAP Fram= ework may not need to define what Measurement Method is and leave it to IPP= M, perhaps in its Performance Registry work, to define. But I believe that = the LMAP Framework will have to use the Measurement Method and then referen= ce the definition given by IPPM. That may cause document dependency and del= ay progress of the LMAP Framework.

Regards,
Greg

On Mon, Jun 2, 2014 at 8:22 AM, Juergen Schoen= waelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jun 02, 2014 at 04:0= 9:41PM +0100, philip.eardley@bt.co= m wrote:

>
> Proposal:-
>
> In the Intro, add to the paragraph about Active & Passive Tasks: >
> There may also be Measurement Tasks that are intermediate between Pass= ive and Active ones; consideration is outside the initial LMAP work scope.<= br> >
>
>
> In terminology, tweak the definitions:-
>
> Passive Measurement Task: A Measurement Task in which a Measurement Ag= ent observes existing traffic but does not inject Active Measurement Traffi= c.
>
>
>
> Active Measurement Task: A Measurement Task in which a Measurement Age= nt sends Active Measurement Traffic to, or receives it from, one or more ot= her Measurement Agents or Measurement Peers, and perhaps coordinates with t= hem using protocols outside the initial LMAP work scope.
>

And do we remove '(active|passive) measurement method' and do= we try
to get rid nof 'measurement method' altogether (so that IPPM can define and use this term in a way they find it most useful)?

/js

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

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

--bcaec52d5683deeb7a04fadd61ed-- From nobody Mon Jun 2 10:13: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 42BF81A020B for ; Mon, 2 Jun 2014 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Mv0k2qWZmGb7 for ; Mon, 2 Jun 2014 10:13:15 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF6B1A01ED for ; Mon, 2 Jun 2014 10:13:15 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 06CBA12031D; Mon, 2 Jun 2014 13:15:30 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id A4BE1F03B9; Mon, 2 Jun 2014 13:13:03 -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; Mon, 2 Jun 2014 13:13:03 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Mon, 2 Jun 2014 13:13:03 -0400 Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+dpOF5D1/u4woREygoOWBsBIXYgADium/ Message-ID: <2845723087023D4CB5114223779FA9C80178E0CD9A@njfpsrvexg8.research.att.com> References: , <20140602152249.GA16074@elstar.local> In-Reply-To: <20140602152249.GA16074@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/KzHnCll2TvXWpiyBc4xgH7S6JNo Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 02 Jun 2014 17:13:17 -0000 below... ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Monday, June 02, 2014 11:22 AM To: philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-fr= amework-05.txt On Mon, Jun 02, 2014 at 04:09:41PM +0100, philip.eardley@bt.com wrote: > > Proposal:- > > In the Intro, add to the paragraph about Active & Passive Tasks: > > There may also be Measurement Tasks that are intermediate between Passive= and Active ones; consideration is outside the initial LMAP work scope. > > In terminology, tweak the definitions:- > > Passive Measurement Task: A Measurement Task in which a Measurement Agent= observes existing traffic but does not inject Active Measurement Traffic. > > Active Measurement Task: A Measurement Task in which a Measurement Agent = sends Active Measurement Traffic to, or receives it from, one or more other= Measurement Agents or Measurement Peers, and perhaps coordinates with them= using protocols outside the initial LMAP work scope. > And do we remove '(active|passive) measurement method' and do we try to get rid nof 'measurement method' altogether (so that IPPM can define and use this term in a way they find it most useful)? /js [acm] The distinction between active and passive measurement exists in the framew= ork (primarily) to support the privacy considerations section (where it matters= quite a lot, and in an early draft, the definitions only appeared in that section). I think the definitions above are sufficient information for the privacy se= ction. Al From nobody Mon Jun 2 10:34: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 C2A2E1A032C for ; Mon, 2 Jun 2014 10:34: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 Ldg2OQ-OYMWa for ; Mon, 2 Jun 2014 10:34:12 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261ED1A02AA for ; Mon, 2 Jun 2014 10:34:12 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id db12so5604233veb.11 for ; Mon, 02 Jun 2014 10:34:06 -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=Pxf4EqnUzwqnkFBbFC42Zid7BDic7K9xijouf/po/jM=; b=a4XREojaw4oi0B3e8mJXGfCNnLgxSQDxB8en+4Kg8/tJt40Zgy/scc1a99H9taTTAk 7O6bC621BYxcGmYp8MBZAvYWnun/h/1tjEj1Dg9/Sap/yLbXfxFvMiHqM31LjmsFTKAt RjbjUAyaCRA/BteWdvaIEN1RjcibG0zu41Oo5gc59vt6Vqm5BEe1yQhAVB481ZINc9kQ rVO1x+9Pt7zzGiMydlyn3KQZmTvA5YiGsuz5oxFbXPPU/ez9s/BP3VJ4T+oXvFicy1bC A8wIv/TxNeAra2v5AX4jJPmm8FMw7kQ6305duyR3L4KzH4VGd3ip4lEPxhqivvKXnBCp r6mg== MIME-Version: 1.0 X-Received: by 10.220.163.3 with SMTP id y3mr31658789vcx.7.1401730446199; Mon, 02 Jun 2014 10:34:06 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Mon, 2 Jun 2014 10:34:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jun 2014 10:34:06 -0700 Message-ID: From: Greg Mirsky To: "philip.eardley@bt.com" Content-Type: multipart/alternative; boundary=001a1133da665110e004faddcd75 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/xXsR-D8G7FfCCsRqMlh1TrtrL0s Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 02 Jun 2014 17:34:15 -0000 --001a1133da665110e004faddcd75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, thank you for the good capture of my comments. "Didn't like" may be little too strong to characterize my POV and sorry if it came across that way. Please find my notes in-line and tagged by GIM>>. Regards, Greg On Mon, Jun 2, 2014 at 8:09 AM, wrote: > Following up on the thread (after holidays) > > > > current definitions:- > > Passive Measurement Method (Task): A Measurement Method (Task) in which a > Measurement Agent observes existing traffic but does not inject Active > Measurement Traffic. > > > > Active Measurement Task: A Measurement Task in which a Measurement Agent > creates or receives Active Measurement Traffic, by coordinating with one = or > more other Measurement Agents or Measurement Peers using protocols outsid= e > the initial LMAP work scope. > > > > -- > > My view is that the Task is about what the MA does. To answer Barbara=E2= =80=99s > quiz question, it is possible to define the activity as two small Tasks o= r > one larger integrated Task. > > > > I can understand the desire to talk =E2=80=98holistically=E2=80=99 about = the whole > measurement system. But looking at say Fig A4 in > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The > passive monitor is an MA running Passive Task. It observes existing traff= ic > from entities that are, from its perspective, MPs. This traffic could be > user traffic or actually generated by another (Active) Task. As far as th= e > function labelled Passive Monitor is concerned, it doesn=E2=80=99t care. > > > > I thought Barbara=E2=80=99s example of UDP echo makes the good point that= the > client and server ends have a different role so may well have to point to > different registry entries. > > > > I agree with Al that passive and active are two end points of a continuum > and there are techniques in-between the extremes (like Nalini=E2=80=99s c= olour > marking of pkts). I=E2=80=99d prefer to leave it to ippm to work on the s= ubtleties > =E2=80=93 as far as lmap is concerned we know that there=E2=80=99s a regi= stry of tests, > which ippm is proposing to sub-divide into active and passive. Maybe late= r > ippm will decide which sub-registry in-between tests should be in, or tha= t > a new registry is needed, or whatever. I think lmap can live with this > slight uncertainty. > GIM>> As noted in mail to Juergen, LMAP Framework has to use Measurement Method, as that is what being referenced by the Measurement Controller. Perhaps we can shy away from differentiation between Active and Passive methods. > So I think it=E2=80=99s better for the definition of Passive to stick wit= h > =E2=80=9Cobserves=E2=80=9D. > > > > > > Greg didn=E2=80=99t like the formulation =E2=80=9CActive Measurement Meth= od (Task)=E2=80=9D =E2=80=93 if I > remember, he thought it was unclear and wanted it split into two > definitions. Since we already have definitions for Measurement Method and > Measurement Task, I actually think it=E2=80=99s unnecessary to distinguis= h Method & > Task in the Passive & Active definitions. So I suggest deleting the =E2= =80=98Active > Measurement Method=E2=80=99 definition, and similarly making the Passive = definition > just about =E2=80=98Passive Measurement Task=E2=80=99. > > > > Greg also didn=E2=80=99t like the way the Active definition talks about > coordination. I think the point is: whilst some Active Tasks involve the = MA > coordinating with other MPs (examples A1 and A2 in the Appendix =E2=80=93= eg web > server responds to client request), in others (example A3) the Controller > controls the other MA and the first MA just sends it traffic (the MAs don= =E2=80=99t > really coordinate with each other). > > > > -- > > > > Proposal:- > > In the Intro, add to the paragraph about Active & Passive Tasks: > > There may also be Measurement Tasks that are intermediate between Passive > and Active ones; consideration is outside the initial LMAP work scope. > > > > In terminology, tweak the definitions:- > > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. > > GIM>> I think that "observes" is not the same as "collect information > off". Can it be "... in which a Measurement Agent collects information of= f > existing traffic ..."? I think that a Measurement Agent may coordinate it= s > actions in performing Passive Measurement Task with other Measurement > Agents/Peers. More on it below. > > Active Measurement Task: A Measurement Task in which a Measurement Agent > sends Active Measurement Traffic to, or receives it from, one or more oth= er > Measurement Agents or Measurement Peers, and perhaps coordinates with the= m > using protocols outside the initial LMAP work scope > GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And I'd > like to discuss new Measurement Domain object defined as: > The community of Measurement Agents and Measurement Peers that cooperate in > performing a Measurement Task, whether Active or Passive, present a > Measurement Domain. Coordination protocol(s) used within Measurement Doma= in > are outside of the initial LMAP work scope. > Then in definitions of Active/Passive Measurement Task in the LMAP Framework we can use the Measurement Domain like: Passive Measurement Task: A Measurement Task in which a Measurement Agent collects information off existing traffic within its Measurement Domain. > > > Best wishes > > phil > > > > > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a1133da665110e004faddcd75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
thank you for the good ca= pture of my comments. "Didn't like" may be little too strong = to characterize my POV and sorry if it came across that way. Please find my= notes in-line and tagged by GIM>>.

Regards,
Greg


On Mon, Jun 2, 2014 at 8:09 AM, &= lt;philip.eardle= y@bt.com> wrote:

Following up on the thread (after holida= ys)

=C2=A0

current definitions:-

Pas= sive Measurement Method (Task): A Measurement Method (Task) in which a Meas= urement Agent observes existing traffic but does not inject Active Measurem= ent Traffic.

=C2=A0

Active Measurement Task: A Measurement Task i= n which a Measurement Agent creates or receives Active Measurement Traffic,= by coordinating with one or more other Measurement Agents or Measurement P= eers using protocols outside the initial LMAP work scope.

=C2=A0

--

My view is that the Ta= sk is about what the MA does. To answer Barbara=E2=80=99s quiz question, it= is possible to define the activity as two small Tasks or one larger integr= ated Task.

=C2=A0

I can understand the desire to talk =E2=80=98= holistically=E2=80=99 about the whole measurement system. But looking at sa= y Fig A4 in http://tools.ietf.org/html/draft-ietf-lma= p-framework-05#section-10 The passive monitor is an MA running Passive = Task. It observes existing traffic from entities that are, from its perspec= tive, MPs. This traffic could be user traffic or actually generated by anot= her (Active) Task. As far as the function labelled Passive Monitor is conce= rned, it doesn=E2=80=99t care.

=C2=A0

I thought Barbara=E2=80=99s example of UDP ec= ho makes the good point that the client and server ends have a different ro= le so may well have to point to different registry entries.

=C2=A0

I agree with Al that passive and active are two end points of a continuu= m and there are techniques in-between the extremes (like Nalini=E2=80=99s c= olour marking of pkts). I=E2=80=99d prefer to leave it to ippm to work on t= he subtleties =E2=80=93 as far as lmap is concerned we know that there=E2= =80=99s a registry of tests, which ippm is proposing to sub-divide into act= ive and passive. Maybe later ippm will decide which sub-registry in-between= tests should be in, or that a new registry is needed, or whatever. I think= lmap can live with this slight uncertainty.

GIM>> As noted in mail to Juergen, LMAP= Framework has to use Measurement Method, as that is what being referenced = by the Measurement Controller. Perhaps we can shy away from differentiation= between Active and Passive methods.=C2=A0

So I think it= =E2=80=99s better for the definition of Passive to stick with =E2=80=9Cobse= rves=E2=80=9D.

=C2=A0

=C2=A0

Greg didn=E2=80=99= t like the formulation =E2=80=9CActive Measurement Method (Task)=E2=80=9D = =E2=80=93 if I remember, he thought it was unclear and wanted it split into= two definitions. Since we already have definitions for Measurement Method = and Measurement Task, I actually think it=E2=80=99s unnecessary to distingu= ish Method & Task in the Passive & Active definitions. So I suggest= deleting the =E2=80=98Active Measurement Method=E2=80=99 definition, and s= imilarly making the Passive definition just about =E2=80=98Passive Measurem= ent Task=E2=80=99.

=C2=A0

Greg also didn=E2=80=99t like the way the Act= ive definition talks about coordination. I think the point is: whilst some = Active Tasks involve the MA coordinating with other MPs (examples A1 and A2= in the Appendix =E2=80=93 eg web server responds to client request), in ot= hers (example A3) the Controller controls the other MA and the first MA jus= t sends it traffic (the MAs don=E2=80=99t really coordinate with each other= ). =C2=A0

=C2=A0

--

=C2=A0

Proposal:-

In the Intro, add to the paragraph abou= t Active & Passive Tasks:

There may also be Measure= ment Tasks that are intermediate between Passive and Active ones; considera= tion is outside the initial LMAP work scope.

=C2=A0

In terminology, tweak the definitions:-

Passive Measurement Task: A Measurement Task in which a Meas= urement Agent observes existing traffic but does not inject Active Measurem= ent Traffic.

GIM>> I think that "observes" is not the same as "c= ollect information off". Can it be "... in which a Measurement Ag= ent collects information off existing traffic ..."? I think that a Mea= surement Agent may coordinate its actions in performing Passive Measurement= Task with other Measurement Agents/Peers. More on it below.

Active Measurement Task: A Measurement Task in which a Measurement A= gent sends Active Measurement Traffic to, or receives it from, one or more = other Measurement Agents or Measurement Peers, and perhaps coordinates with= them using protocols outside the initial LMAP work scope

=

GIM>> Is &= quot;Active Measurement Traffic" the same as "Test Traffic"?= And I'd like to discuss new Measurement Domain object defined as:=C2= =A0

=

The community of= Measurement Agents and Measurement Peers that cooperate in performing a Me= asurement Task, whether Active or Passive, present a Measurement Domain. Co= ordination protocol(s) used within Measurement Domain are outside of the in= itial LMAP work scope.

Then in definitions of Active/Passive Measurem= ent Task in the LMAP Framework we can use the Measurement Domain like:
P= assive Measurement Task: A Measurement Task in which a Measurement Agent co= llects information off existing traffic within its Measurement Domain.

=C2=A0

Best w= ishes

phil

=C2=A0

=C2=A0=

=C2=A0


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


--001a1133da665110e004faddcd75-- From nobody Mon Jun 2 13:32: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 051E31A0446 for ; Mon, 2 Jun 2014 13:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 VQJOnCpdqxmV for ; Mon, 2 Jun 2014 13:32:22 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3771A0410 for ; Mon, 2 Jun 2014 13:32:22 -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 15fdc835.2ae5cf61e940.7553209.00-2451.20886046.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 02 Jun 2014 20:32:17 +0000 (UTC) X-MXL-Hash: 538cdf51223168b1-5023eed5c0d15939ad59a7663847cb2e3933860e 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 e4fdc835.0.7553163.00-2227.20885891.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 02 Jun 2014 20:32:15 +0000 (UTC) X-MXL-Hash: 538cdf4f31bcacf2-409504b1b10eac7c9c44aa9afce7d32ec9f128e3 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 s52KWDRi031385; Mon, 2 Jun 2014 16:32:13 -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 s52KW7ES031306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 16:32:08 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 2 Jun 2014 20:31:51 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 16:31:50 -0400 From: "STARK, BARBARA H" To: Greg Mirsky , "philip.eardley@bt.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojkbNHfyGX67kmnH/9tHgk7xZtePLUg Date: Mon, 2 Jun 2014 20:31:50 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE5217@GAALPA1MSGUSRBF.ITServices.sbc.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.70.194.134] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE5217GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4KGvShVWWqUA:10 a=ofMgfj31e3cA:10 a=K1xZumjKIH0A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=Nl_lTHnL7] X-AnalysisOut: [JS6bAj2BksA:9 a=QEXdDO2ut3YA:10 a=VUQ4w9tI6KsA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A] X-AnalysisOut: [:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=kGGkqyZSVZcA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hew7F1bq0M5z50jE1W0TbhKglEc Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 02 Jun 2014 20:32:25 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE5217GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4tbGluZS4NCkJhcmJhcmENCg0KR0lNPj4gQXMgbm90ZWQgaW4gbWFpbCB0byBKdWVyZ2VuLCBM TUFQIEZyYW1ld29yayBoYXMgdG8gdXNlIE1lYXN1cmVtZW50IE1ldGhvZCwgYXMgdGhhdCBpcyB3 aGF0IGJlaW5nIHJlZmVyZW5jZWQgYnkgdGhlIE1lYXN1cmVtZW50IENvbnRyb2xsZXIuIFBlcmhh cHMgd2UgY2FuIHNoeSBhd2F5IGZyb20gZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gQWN0aXZlIGFu ZCBQYXNzaXZlIG1ldGhvZHMuDQoNCjxiaHM+IEkgZGlzYWdyZWUgdGhhdCB0aGUgTWVhc3VyZW1l bnQgQ29udHJvbGxlciBpcyByZWZlcmVuY2luZyB0aGUg4oCcaG9saXN0aWMgdGVjaG5pcXVl4oCd LiBJIHRoaW5rIHRoZSBNZWFzdXJlbWVudCBDb250cm9sbGVyIGlzIG9ubHkgcmVmZXJlbmNpbmcg dGhlIHNwZWNpZmljIHJvbGUgd2l0aGluIHRoYXQgaG9saXN0aWMgdGVjaG5pcXVlIHRoYXQgdGhl IENvbnRyb2xsZXIgbmVlZHMgdG8gaW5zdHJ1Y3QgYW4gTUEgdG8gZG8uIEFzc3VtaW5nIGEgc2lu Z2xlIENvbnRyb2xsZXIgY29tbXVuaWNhdGVzIHdpdGggYWxsIHBvaW50cyBvZiBhIGhvbGlzdGlj IHRlY2huaXF1ZSBkb2VzbuKAmXQgc2NhbGUuIFNvIHdlIGNhbuKAmXQgcHJlY2x1ZGUgdGhlIHBv c3NpYmlsaXR5IHRoYXQgZGlmZmVyZW50IENvbnRyb2xsZXJzIGNvbW11bmljYXRlIHdpdGggZGlm ZmVyZW50IE1BcywgYW5kIHRoYXQgc29tZSBPcGVyYXRpb25zIFN5c3RlbSBjb21tdW5pY2F0ZXMg d2l0aCBhbGwgQ29udHJvbGxlcnMgaW4gb3JkZXIgdG8gY29vcmRpbmF0ZSB0aGVtLiBOb3RoaW5n IGluIHRoZSBjdXJyZW50IExNQVAgZnJhbWV3b3JrIGFyY2hpdGVjdHVyZSBlaXRoZXIgYXNzdW1l cyBvciByZXF1aXJlcyB0aGUgQ29udHJvbGxlciB0byBoYXZlIGEgaG9saXN0aWMgdmlldy4gU2lt aWxhcmx5LCBhIHNpbmdsZSBDb2xsZWN0b3IgZG9lc27igJl0IGhhdmUgdG8gY29sbGVjdCBhbGwg cmVzdWx0cyBmb3IgYSBob2xpc3RpYyB0ZWNobmlxdWUuIEluIGZyYW1ld29yayBGaWd1cmUgMSwg dGhlIENvbGxlY3RvciBmZWVkcyB0aGUgcmVwb3NpdG9yeS4gQXMgbG9uZyBhcyBhbGwgdGhlIGNv bGxlY3RlZCBkYXRhIG1ha2VzIGl0IHRvIHRoZSByZXBvc2l0b3J5IChldmVuIGlmIGl0IGFsbCBj b21lcyBmcm9tIGRpZmZlcmVudCBDb2xsZWN0b3JzKSwgdGhlIGRhdGEgYW5hbHlzaXMgdG9vbHMg YXJlIGV4cGVjdGVkIHRvIGJlIGFibGUgdG8gY29tYmluZSB0aGUgcmVzdWx0cyB0aGF0IHdlcmUg cGFydCBvZiBhIGhvbGlzdGljIHRlY2huaXF1ZS4NCg0KVGhlIG9wZXJhdG9yIG9mIHRoZSBtZWFz dXJlbWVudCBmcmFtZXdvcmsgbmVlZHMgdG8gaGF2ZSB0aGUgaG9saXN0aWMgdmlldy4gTm9uZSBv ZiB0aGUgZGVmaW5lZCBMTUFQIGVsZW1lbnRzIG5lZWRzIHN1Y2ggYSB2aWV3LiBJIGRvbuKAmXQg Y29uc2lkZXIgdGhlIHJlZ2lzdHJ5IHRvIGJlIGFuIExNQVAgZWxlbWVudCwgc2luY2UgaXTigJlz IGNvbWluZyBmcm9tIElQUE0uIEJ1dCBldmVuIHRoZXJlLCB0aGUgcmVxdWlyZW1lbnQgdGhhdCBM TUFQIHBsYWNlcyB1cG9uIHRoZSByZWdpc3RyeSwgaXMgZm9yIHRoZSByZWdpc3RyeSB0byBwcm92 aWRlIGVub3VnaCBncmFudWxhcml0eSB0aGF0IHRoZSBDb250cm9sbGVyIGtub3dzIHRoZSBpbnB1 dHMgbmVlZGVkIGZvciB0aGUgcGFydGljdWxhciByb2xlIGFuIE1BIG5lZWRzIHRvIHBsYXkgaW4g YSBob2xpc3RpYyB0ZWNobmlxdWUuIFRoZSByZWdpc3RyeSBVUkwgdGhhdCBpcyBhc3NvY2lhdGVk IHdpdGggYSBNZWFzdXJlbWVudCBUYXNrIHJlYWxseSBuZWVkcyB0byBiZSBzcGVjaWZpYyB0byB0 aGUgTUHigJlzIHJvbGUgaW4gdGhlIGhvbGlzdGljIHRlY2huaXF1ZS4NCg0KLS0NCg0KR0lNPj4g SXMgIkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIiB0aGUgc2FtZSBhcyAiVGVzdCBUcmFmZmlj Ij8gQW5kIEknZCBsaWtlIHRvIGRpc2N1c3MgbmV3IE1lYXN1cmVtZW50IERvbWFpbiBvYmplY3Qg ZGVmaW5lZCBhczoNCg0KVGhlIGNvbW11bml0eSBvZiBNZWFzdXJlbWVudCBBZ2VudHMgYW5kIE1l YXN1cmVtZW50IFBlZXJzIHRoYXQgY29vcGVyYXRlIGluIHBlcmZvcm1pbmcgYSBNZWFzdXJlbWVu dCBUYXNrLCB3aGV0aGVyIEFjdGl2ZSBvciBQYXNzaXZlLCBwcmVzZW50IGEgTWVhc3VyZW1lbnQg RG9tYWluLiBDb29yZGluYXRpb24gcHJvdG9jb2wocykgdXNlZCB3aXRoaW4gTWVhc3VyZW1lbnQg RG9tYWluIGFyZSBvdXRzaWRlIG9mIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZS4NCg0KPGJo cz4gSSBkaXNhZ3JlZSB3aXRoIHRoaXMgdXNlIG9mIE1lYXN1cmVtZW50IFRhc2suIE1lYXN1cmVt ZW50IFRhc2sgaXMgc3BlY2lmaWMgdG8gYSBNQS4gSWYgbXVsdGlwbGUgTUFzIGFuZCBNUHMgY29v cGVyYXRlIGluIGFuIGluc3RhbnRpYXRpb24gb2YgYSBob2xpc3RpYyB0ZWNobmlxdWUsIHRoZW4g ZWFjaCBNQSBhbmQgTVAgaXMgcGVyZm9ybWluZyBhIE1lYXN1cmVtZW50IFRhc2suIElmIElQUE0g dGFrZXMgb3ZlciB0aGlzIHRlcm0sIHRvbywgYW5kIHRyaWVzIHRvIG1ha2UgaXQgaG9saXN0aWMs IEkgdGhpbmsgdGhhdCB3aWxsIGNhdXNlIHdheSB0b28gbXVjaCByZXdvcmsgaW4gTE1BUCB0byBj cmVhdGUgYSBuZXcgdGVybSBmb3IgdGhlIGluc3RhbnRpYXRpb24gb2YgYW4gTUEtc3BlY2lmaWMg cm9sZSBhbmQgcmVwbGFjZSBNZWFzdXJlbWVudCBUYXNrIGluIGFsbCBpbnN0YW5jZXMgd2l0aCB0 aGUgbmV3IHRlcm0uIElmIElQUE0gbmVlZHMgYSB0ZXJtIGZvciB0aGUgaW5zdGFudGlhdGlvbiBv ZiBhIGhvbGlzdGljIHRlY2huaXF1ZSwgaXQgc2hvdWxkIGludmVudCBhIG5ldyB0ZXJtLiBJ4oCZ bSBhbHNvIG5vdCBzdXJlIHRoaXMgbmV3IHRlcm0g4oCcTWVhc3VyZW1lbnQgRG9tYWlu4oCdIGlz IG5lZWRlZCwgb3IgdGhhdCBJIHdvdWxkIGNhbGwgd2hhdCB5b3UgZGVzY3JpYmUgYSBNZWFzdXJl bWVudCBEb21haW4uIEZyYW1ld29yayBhbHJlYWR5IHRhbGtzIGFib3V0IG9wZXJhdGlvbmFsIGRv bWFpbiBhbmQgTE1BUCBkb21haW4uIExNQVAgZG9tYWluIGlzIOKAnHRoZSBzeXN0ZW0gb2YgZnVu Y3Rpb25zIGRlcGxveWVkIGJ5IGEgc2luZ2xlIG9yZ2FuaXNhdGlvbiBbdG8gZG8gbGFyZ2Utc2Nh bGUgbWVhc3VyZW1lbnRzXeKAnS4gVG8gdXNlIHRoZSB3b3JkIOKAnGRvbWFpbuKAnSB0byBkZXNj cmliZSBqdXN0IHRoZSBNQXMgaW52b2x2ZWQgaW4gYSBzaW5nbGUgaW5zdGFudGlhdGlvbiBvZiBh IGhvbGlzdGljIHRlY2huaXF1ZSBzZWVtcyB0byBub3QgYmUgYSBnb29kIHVzZSBvZiDigJxkb21h aW7igJ0gdG8gbWUuDQoNCkJhcmJhcmENCg== --_000_2D09D61DDFA73D4C884805CC7865E61130DE5217GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Jbi1saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CYXJiYXJhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+R0lNJmd0OyZndDsgQXMgbm90ZWQgaW4gbWFpbCB0byBKdWVyZ2Vu LCBMTUFQIEZyYW1ld29yayBoYXMgdG8gdXNlIE1lYXN1cmVtZW50IE1ldGhvZCwgYXMgdGhhdCBp cyB3aGF0IGJlaW5nIHJlZmVyZW5jZWQgYnkgdGhlIE1lYXN1cmVtZW50IENvbnRyb2xsZXIuIFBl cmhhcHMgd2UgY2FuIHNoeSBhd2F5IGZyb20gZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gQWN0aXZl IGFuZCBQYXNzaXZlIG1ldGhvZHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O2JocyZndDsgSSBkaXNhZ3JlZSB0 aGF0IHRoZSBNZWFzdXJlbWVudCBDb250cm9sbGVyIGlzIHJlZmVyZW5jaW5nIHRoZSDigJxob2xp c3RpYyB0ZWNobmlxdWXigJ0uIEkgdGhpbmsgdGhlIE1lYXN1cmVtZW50IENvbnRyb2xsZXIgaXMg b25seSByZWZlcmVuY2luZyB0aGUgc3BlY2lmaWMNCiByb2xlIHdpdGhpbiB0aGF0IGhvbGlzdGlj IHRlY2huaXF1ZSB0aGF0IHRoZSBDb250cm9sbGVyIG5lZWRzIHRvIGluc3RydWN0IGFuIE1BIHRv IGRvLiBBc3N1bWluZyBhIHNpbmdsZSBDb250cm9sbGVyIGNvbW11bmljYXRlcyB3aXRoIGFsbCBw b2ludHMgb2YgYSBob2xpc3RpYyB0ZWNobmlxdWUgZG9lc27igJl0IHNjYWxlLiBTbyB3ZSBjYW7i gJl0IHByZWNsdWRlIHRoZSBwb3NzaWJpbGl0eSB0aGF0IGRpZmZlcmVudCBDb250cm9sbGVycyBj b21tdW5pY2F0ZQ0KIHdpdGggZGlmZmVyZW50IE1BcywgYW5kIHRoYXQgc29tZSBPcGVyYXRpb25z IFN5c3RlbSBjb21tdW5pY2F0ZXMgd2l0aCBhbGwgQ29udHJvbGxlcnMgaW4gb3JkZXIgdG8gY29v cmRpbmF0ZSB0aGVtLiBOb3RoaW5nIGluIHRoZSBjdXJyZW50IExNQVAgZnJhbWV3b3JrIGFyY2hp dGVjdHVyZSBlaXRoZXIgYXNzdW1lcyBvciByZXF1aXJlcyB0aGUgQ29udHJvbGxlciB0byBoYXZl IGEgaG9saXN0aWMgdmlldy4gU2ltaWxhcmx5LCBhIHNpbmdsZSBDb2xsZWN0b3INCiBkb2VzbuKA mXQgaGF2ZSB0byBjb2xsZWN0IGFsbCByZXN1bHRzIGZvciBhIGhvbGlzdGljIHRlY2huaXF1ZS4g SW4gZnJhbWV3b3JrIEZpZ3VyZSAxLCB0aGUgQ29sbGVjdG9yIGZlZWRzIHRoZSByZXBvc2l0b3J5 LiBBcyBsb25nIGFzIGFsbCB0aGUgY29sbGVjdGVkIGRhdGEgbWFrZXMgaXQgdG8gdGhlIHJlcG9z aXRvcnkgKGV2ZW4gaWYgaXQgYWxsIGNvbWVzIGZyb20gZGlmZmVyZW50IENvbGxlY3RvcnMpLCB0 aGUgZGF0YSBhbmFseXNpcyB0b29scw0KIGFyZSBleHBlY3RlZCB0byBiZSBhYmxlIHRvIGNvbWJp bmUgdGhlIHJlc3VsdHMgdGhhdCB3ZXJlIHBhcnQgb2YgYSBob2xpc3RpYyB0ZWNobmlxdWUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgb3BlcmF0b3Igb2YgdGhlIG1lYXN1cmVtZW50IGZyYW1ld29yayBuZWVkcyB0 byBoYXZlIHRoZSBob2xpc3RpYyB2aWV3LiBOb25lIG9mIHRoZSBkZWZpbmVkIExNQVAgZWxlbWVu dHMgbmVlZHMgc3VjaCBhIHZpZXcuIEkgZG9u4oCZdCBjb25zaWRlciB0aGUgcmVnaXN0cnkNCiB0 byBiZSBhbiBMTUFQIGVsZW1lbnQsIHNpbmNlIGl04oCZcyBjb21pbmcgZnJvbSBJUFBNLiBCdXQg ZXZlbiB0aGVyZSwgdGhlIHJlcXVpcmVtZW50IHRoYXQgTE1BUCBwbGFjZXMgdXBvbiB0aGUgcmVn aXN0cnksIGlzIGZvciB0aGUgcmVnaXN0cnkgdG8gcHJvdmlkZSBlbm91Z2ggZ3JhbnVsYXJpdHkg dGhhdCB0aGUgQ29udHJvbGxlciBrbm93cyB0aGUgaW5wdXRzIG5lZWRlZCBmb3IgdGhlIHBhcnRp Y3VsYXIgcm9sZSBhbiBNQSBuZWVkcyB0byBwbGF5DQogaW4gYSBob2xpc3RpYyB0ZWNobmlxdWUu IFRoZSByZWdpc3RyeSBVUkwgdGhhdCBpcyBhc3NvY2lhdGVkIHdpdGggYSBNZWFzdXJlbWVudCBU YXNrIHJlYWxseSBuZWVkcyB0byBiZSBzcGVjaWZpYyB0byB0aGUgTUHigJlzIHJvbGUgaW4gdGhl IGhvbGlzdGljIHRlY2huaXF1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+R0lNJmd0OyZndDsgSXMgJnF1b3Q7 QWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMmcXVvdDsgdGhlIHNhbWUgYXMgJnF1b3Q7VGVzdCBU cmFmZmljJnF1b3Q7PyBBbmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1lbnQgRG9t YWluIG9iamVjdCBkZWZpbmVkIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGNvbW11bml0eSBvZiBNZWFzdXJlbWVudCBBZ2VudHMgYW5k IE1lYXN1cmVtZW50IFBlZXJzIHRoYXQgY29vcGVyYXRlIGluIHBlcmZvcm1pbmcgYSBNZWFzdXJl bWVudCBUYXNrLCB3aGV0aGVyIEFjdGl2ZSBvciBQYXNzaXZlLCBwcmVzZW50IGEgTWVhc3VyZW1l bnQgRG9tYWluLiBDb29yZGluYXRpb24gcHJvdG9jb2wocykgdXNlZCB3aXRoaW4gTWVhc3VyZW1l bnQgRG9tYWluIGFyZSBvdXRzaWRlIG9mDQogdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O2JocyZndDsgSSBkaXNhZ3JlZSB3aXRoIHRoaXMg dXNlIG9mIE1lYXN1cmVtZW50IFRhc2suIE1lYXN1cmVtZW50IFRhc2sgaXMgc3BlY2lmaWMgdG8g YSBNQS4gSWYgbXVsdGlwbGUgTUFzIGFuZCBNUHMgY29vcGVyYXRlIGluIGFuIGluc3RhbnRpYXRp b24gb2YgYSBob2xpc3RpYyB0ZWNobmlxdWUsDQogdGhlbiBlYWNoIE1BIGFuZCBNUCBpcyBwZXJm b3JtaW5nIGEgTWVhc3VyZW1lbnQgVGFzay4gSWYgSVBQTSB0YWtlcyBvdmVyIHRoaXMgdGVybSwg dG9vLCBhbmQgdHJpZXMgdG8gbWFrZSBpdCBob2xpc3RpYywgSSB0aGluayB0aGF0IHdpbGwgY2F1 c2Ugd2F5IHRvbyBtdWNoIHJld29yayBpbiBMTUFQIHRvIGNyZWF0ZSBhIG5ldyB0ZXJtIGZvciB0 aGUgaW5zdGFudGlhdGlvbiBvZiBhbiBNQS1zcGVjaWZpYyByb2xlIGFuZCByZXBsYWNlIE1lYXN1 cmVtZW50DQogVGFzayBpbiBhbGwgaW5zdGFuY2VzIHdpdGggdGhlIG5ldyB0ZXJtLiBJZiBJUFBN IG5lZWRzIGEgdGVybSBmb3IgdGhlIGluc3RhbnRpYXRpb24gb2YgYSBob2xpc3RpYyB0ZWNobmlx dWUsIGl0IHNob3VsZCBpbnZlbnQgYSBuZXcgdGVybS4gSeKAmW0gYWxzbyBub3Qgc3VyZSB0aGlz IG5ldyB0ZXJtIOKAnE1lYXN1cmVtZW50IERvbWFpbuKAnSBpcyBuZWVkZWQsIG9yIHRoYXQgSSB3 b3VsZCBjYWxsIHdoYXQgeW91IGRlc2NyaWJlIGEgTWVhc3VyZW1lbnQgRG9tYWluLg0KIEZyYW1l d29yayBhbHJlYWR5IHRhbGtzIGFib3V0IG9wZXJhdGlvbmFsIGRvbWFpbiBhbmQgTE1BUCBkb21h aW4uIExNQVAgZG9tYWluIGlzIOKAnHRoZSBzeXN0ZW0gb2YgZnVuY3Rpb25zIGRlcGxveWVkIGJ5 IGEgc2luZ2xlIG9yZ2FuaXNhdGlvbiBbdG8gZG8gbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnRzXeKA nS4gVG8gdXNlIHRoZSB3b3JkIOKAnGRvbWFpbuKAnSB0byBkZXNjcmliZSBqdXN0IHRoZSBNQXMg aW52b2x2ZWQgaW4gYSBzaW5nbGUgaW5zdGFudGlhdGlvbg0KIG9mIGEgaG9saXN0aWMgdGVjaG5p cXVlIHNlZW1zIHRvIG5vdCBiZSBhIGdvb2QgdXNlIG9mIOKAnGRvbWFpbuKAnSB0byBtZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E61130DE5217GAALPA1MSGUSRBF_-- From nobody Mon Jun 2 23:29: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 7C2FA1A010B for ; Mon, 2 Jun 2014 23:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 mfcEUteNX6m1 for ; Mon, 2 Jun 2014 23:29:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E661A010D for ; Mon, 2 Jun 2014 23:29:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEU74942; Tue, 03 Jun 2014 06:28:57 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 07:28:12 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 07:28:56 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 14:28:53 +0800 From: Mach Chen To: "philip.eardley@bt.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+c1IuW/beYBhwTt+OiwOS2H6N3AAfK65AAAAEd0A= Date: Tue, 3 Jun 2014 06:28:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/Df8kZHropBIkYPYfHKhHlT11pa0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 03 Jun 2014 06:29:08 -0000 Hi Phil, > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. Given that there are some existing passive measurement solutions (e.g., Y.1= 731, RFC6374 (direct mode)) that may inject extra traffic to help measuring= , I am not sure whether "does not inject Active Measurement Traffic" is sti= ll one of the characteristics of Passive Measurement. IMHO, it's better fro= m the tested object point of view (e.g., for a measurement task, whether th= e tested object is the existing traffic or injected traffic) to describe wh= at is Passive and Active measurement.=20 In addition, I like Greg's idea to change "observes" to "collects informati= on of".=20 Best regards, Mach > -----Original Message----- > From: Mach Chen > Sent: Tuesday, June 03, 2014 1:53 PM > To: Mach Chen > Subject: FW: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt >=20 >=20 >=20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.= com > Sent: Monday, June 02, 2014 11:10 PM > To: lmap@ietf.org > Subject: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt >=20 > Following up on the thread (after holidays) >=20 > current definitions:- > Passive Measurement Method (Task): A Measurement Method (Task) in which a > Measurement Agent observes existing traffic but does not inject Active > Measurement Traffic. >=20 > Active Measurement Task: A Measurement Task in which a Measurement Agent > creates or receives Active Measurement Traffic, by coordinating with one = or > more other Measurement Agents or Measurement Peers using protocols > outside the initial LMAP work scope. >=20 > -- > My view is that the Task is about what the MA does. To answer Barbara's q= uiz > question, it is possible to define the activity as two small Tasks or one= larger > integrated Task. >=20 > I can understand the desire to talk 'holistically' about the whole measur= ement > system. But looking at say Fig A4 in > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The pa= ssive > monitor is an MA running Passive Task. It observes existing traffic from = entities > that are, from its perspective, MPs. This traffic could be user traffic o= r actually > generated by another (Active) Task. As far as the function labelled Passi= ve > Monitor is concerned, it doesn't care. >=20 > I thought Barbara's example of UDP echo makes the good point that the cli= ent > and server ends have a different role so may well have to point to differ= ent > registry entries. >=20 > I agree with Al that passive and active are two end points of a continuum= and > there are techniques in-between the extremes (like Nalini's colour markin= g of > pkts). I'd prefer to leave it to ippm to work on the subtleties - as far = as lmap is > concerned we know that there's a registry of tests, which ippm is proposi= ng to > sub-divide into active and passive. Maybe later ippm will decide which > sub-registry in-between tests should be in, or that a new registry is nee= ded, or > whatever. I think lmap can live with this slight uncertainty. > So I think it's better for the definition of Passive to stick with "obser= ves". >=20 >=20 > Greg didn't like the formulation "Active Measurement Method (Task)" - if = I > remember, he thought it was unclear and wanted it split into two definiti= ons. > Since we already have definitions for Measurement Method and Measurement > Task, I actually think it's unnecessary to distinguish Method & Task in t= he Passive > & Active definitions. So I suggest deleting the 'Active Measurement Metho= d' > definition, and similarly making the Passive definition just about 'Passi= ve > Measurement Task'. >=20 > Greg also didn't like the way the Active definition talks about coordinat= ion. I > think the point is: whilst some Active Tasks involve the MA coordinating = with > other MPs (examples A1 and A2 in the Appendix - eg web server responds to > client request), in others (example A3) the Controller controls the other= MA and > the first MA just sends it traffic (the MAs don't really coordinate with = each > other). >=20 > -- >=20 > Proposal:- > In the Intro, add to the paragraph about Active & Passive Tasks: > There may also be Measurement Tasks that are intermediate between Passive > and Active ones; consideration is outside the initial LMAP work scope. >=20 > In terminology, tweak the definitions:- > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. >=20 > Active Measurement Task: A Measurement Task in which a Measurement Agent > sends Active Measurement Traffic to, or receives it from, one or more oth= er > Measurement Agents or Measurement Peers, and perhaps coordinates with > them using protocols outside the initial LMAP work scope. >=20 >=20 > Best wishes > phil >=20 >=20 From nobody Tue Jun 3 00:38: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 7E86F1A0114 for ; Tue, 3 Jun 2014 00:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dVTmpIzOkafN for ; Tue, 3 Jun 2014 00:38:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC001A0043 for ; Tue, 3 Jun 2014 00:38:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHT96627; Tue, 03 Jun 2014 07:38:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:37:40 +0100 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 08:38:23 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.103]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 15:38:12 +0800 From: Vero Zheng To: Greg Mirsky , "philip.eardley@bt.com" , Mach Chen Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojiBXIBsdgvek+/50hSxhGmp5te9Z7g Date: Tue, 3 Jun 2014 07:38:11 +0000 Message-ID: <2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2@SZXEMA504-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.115] Content-Type: multipart/alternative; boundary="_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ufj7JBiZRyk7tH2sg3BztmzOAe0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 03 Jun 2014 07:38:35 -0000 --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2SZXEMA504MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNClByb3Bvc2FsOi0NCg0KSW4gdGVybWlu b2xvZ3ksIHR3ZWFrIHRoZSBkZWZpbml0aW9uczotDQoNClBhc3NpdmUgTWVhc3VyZW1lbnQgVGFz azogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgb2JzZXJ2 ZXMgZXhpc3RpbmcgdHJhZmZpYyBidXQgZG9lcyBub3QgaW5qZWN0IEFjdGl2ZSBNZWFzdXJlbWVu dCBUcmFmZmljLg0KDQpHSU0+PiBJIHRoaW5rIHRoYXQgIm9ic2VydmVzIiBpcyBub3QgdGhlIHNh bWUgYXMgImNvbGxlY3QgaW5mb3JtYXRpb24gb2ZmIi4gQ2FuIGl0IGJlICIuLi4gaW4gd2hpY2gg YSBNZWFzdXJlbWVudCBBZ2VudCBjb2xsZWN0cyBpbmZvcm1hdGlvbiBvZmYgZXhpc3RpbmcgdHJh ZmZpYyAuLi4iPyBJIHRoaW5rIHRoYXQgYSBNZWFzdXJlbWVudCBBZ2VudCBtYXkgY29vcmRpbmF0 ZSBpdHMgYWN0aW9ucyBpbiBwZXJmb3JtaW5nIFBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzayB3aXRo IG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4gTW9yZSBvbiBpdCBiZWxvdy4NClZlcm8+ PkkgdGhpbmsgR3JlZ+KAmXMgc3VnZ2VzdGlvbiBvZiB1c2luZyDigJxjb2xsZWN0IGluZm9ybWF0 aW9uIG9mZuKAnSBpcyBhIGJldHRlciBpZGVhLiBJdHMgbW9yZSBnZW5lcmljIHRoYW4g4oCcb2Jz ZXJ2ZXPigJ0uDQoNCkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sg aW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBzZW5kcyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJh ZmZpYyB0bywgb3IgcmVjZWl2ZXMgaXQgZnJvbSwgb25lIG9yIG1vcmUgb3RoZXIgTWVhc3VyZW1l bnQgQWdlbnRzIG9yIE1lYXN1cmVtZW50IFBlZXJzLCBhbmQgcGVyaGFwcyBjb29yZGluYXRlcyB3 aXRoIHRoZW0gdXNpbmcgcHJvdG9jb2xzIG91dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNj b3BlDQpHSU0+PiBJcyAiQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMiIHRoZSBzYW1lIGFzICJU ZXN0IFRyYWZmaWMiPw0KDQpWZXJvPj4gdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiBBY3RpdmUg TWVhc3VyZW1lbnQgVHJhZmZpYzogIHRoZSBwYWNrZXQocykgZ2VuZXJhdGVkIGluIG9yZGVyIHRv ICBleGVjdXRlIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLg0KQXMgTWFjaCBwb2ludGVkIG91 dCBpbiBoaXMgbm90ZSwgdGVjaG5vbG9naWVzIGxpa2UgSVRVLVQgWS4xNzMxLCBSRkMgNjM3NCBh cmUgZ2VuZXJhdGluZyBPQU0gcGFja2V0cywgd2hpY2ggZGVsaW1pdGluZyB0aGUgZXhpc3Rpbmcg cGFja2V0cyBhbmQgY2FycnlpbmcgdGhlIGluZm9ybWF0aW9uIG9mIGV4aXN0aW5nIHRyYWZmaWMs IGUuZy4gcGFja2V0IGNvdW50cyBhbmQgdGltZXN0YW1wcy4gVGhlc2UgbWVhc3VyZW1lbnQgbWV0 aG9kIGdlbmVyYXRlIHBhY2tldHMgaW4gb3JkZXIgdG8gZXhlY3V0ZSBhbiBtZWFzdXJlbWVudCB0 YXNrLCBidXQgd2lsbCB5b3UgY29uc2lkZXIgdGhlbSBhcyBBY3RpdmUgTWVhc3VyZW1lbnQgTWV0 aG9kPyBNeSBhbnN3ZXIgd2lsbCBiZSBOTy4gRXZlbiB0aG91Z2ggT0FNIHBhY2tldHMgaXMgZ2Vu ZXJhdGVkLCBidXQgdGhlIG1lYXN1cmVtZW50IHRhc2sgaXMgdG8gY29sbGVjdCB0aGUgaW5mb3Jt YXRpb24gb2YgdGhlIGV4aXN0aW5nIHRyYWZmaWMsIG5vdCB0aGUgaW5mb3JtYXRpb24gb2YgdGhl IGdlbmVyYXRlZCBwYWNrZXRzLg0KDQpJIGFncmVlIHdpdGggTWFjaCB0aGF0IGl0J3MgYmV0dGVy IGZyb20gdGhlIHRlc3RlZCBvYmplY3QgcG9pbnQgb2YgdmlldyAoZS5nLiwgZm9yIGEgbWVhc3Vy ZW1lbnQgdGFzaywgd2hldGhlciB0aGUgdGVzdGVkIG9iamVjdCBpcyB0aGUgZXhpc3RpbmcgdHJh ZmZpYyBvciBpbmplY3RlZCB0cmFmZmljKSB0byBkZWZpbmUgd2hhdCBQYXNzaXZlIGFuZCBBY3Rp dmUgbWVhc3VyZW1lbnQgbWV0aG9kL3Rhc2svdHJhZmZpYyBpcy4NCg0KDQpJbiB0aGUgSW50cm8s IGFkZCB0byB0aGUgcGFyYWdyYXBoIGFib3V0IEFjdGl2ZSAmIFBhc3NpdmUgVGFza3M6DQoNClRo ZXJlIG1heSBhbHNvIGJlIE1lYXN1cmVtZW50IFRhc2tzIHRoYXQgYXJlIGludGVybWVkaWF0ZSBi ZXR3ZWVuIFBhc3NpdmUgYW5kIEFjdGl2ZSBvbmVzOyBjb25zaWRlcmF0aW9uIGlzIG91dHNpZGUg dGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlLg0KVmVybz4+IElmIHdlIHR3ZWFrIHRoZSBkZWZp bml0aW9ucyBjYXJlZnVsbHksIHdlIG1heSBkb27igJl0IG5lZWQgdG8gZXhjbHVkZSBhbnkgbWVh c3VyZW1lbnQgdGFza3Mgb3V0c2lkZSBzY29wZS4NCg0KQ2hlZXJzLCBWZXJvDQoNCg0KDQpGcm9t OiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBN aXJza3kNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgMTozNCBBTQ0KVG86IHBoaWxpcC5l YXJkbGV5QGJ0LmNvbQ0KQ2M6IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbG1hcF0gRm9s bG93LXVwIG9uIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdv cmstMDUudHh0DQoNCkhpIFBoaWwsDQp0aGFuayB5b3UgZm9yIHRoZSBnb29kIGNhcHR1cmUgb2Yg bXkgY29tbWVudHMuICJEaWRuJ3QgbGlrZSIgbWF5IGJlIGxpdHRsZSB0b28gc3Ryb25nIHRvIGNo YXJhY3Rlcml6ZSBteSBQT1YgYW5kIHNvcnJ5IGlmIGl0IGNhbWUgYWNyb3NzIHRoYXQgd2F5LiBQ bGVhc2UgZmluZCBteSBub3RlcyBpbi1saW5lIGFuZCB0YWdnZWQgYnkgR0lNPj4uDQpSZWdhcmRz LA0KR3JlZw0KDQpPbiBNb24sIEp1biAyLCAyMDE0IGF0IDg6MDkgQU0sIDxwaGlsaXAuZWFyZGxl eUBidC5jb208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4+IHdyb3RlOg0KDQpGb2xsb3dp bmcgdXAgb24gdGhlIHRocmVhZCAoYWZ0ZXIgaG9saWRheXMpDQoNCg0KDQpjdXJyZW50IGRlZmlu aXRpb25zOi0NCg0KUGFzc2l2ZSBNZWFzdXJlbWVudCBNZXRob2QgKFRhc2spOiBBIE1lYXN1cmVt ZW50IE1ldGhvZCAoVGFzaykgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBvYnNlcnZlcyBl eGlzdGluZyB0cmFmZmljIGJ1dCBkb2VzIG5vdCBpbmplY3QgQWN0aXZlIE1lYXN1cmVtZW50IFRy YWZmaWMuDQoNCg0KDQpBY3RpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNr IGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgY3JlYXRlcyBvciByZWNlaXZlcyBBY3RpdmUg TWVhc3VyZW1lbnQgVHJhZmZpYywgYnkgY29vcmRpbmF0aW5nIHdpdGggb25lIG9yIG1vcmUgb3Ro ZXIgTWVhc3VyZW1lbnQgQWdlbnRzIG9yIE1lYXN1cmVtZW50IFBlZXJzIHVzaW5nIHByb3RvY29s cyBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZS4NCg0KDQoNCi0tDQoNCk15IHZp ZXcgaXMgdGhhdCB0aGUgVGFzayBpcyBhYm91dCB3aGF0IHRoZSBNQSBkb2VzLiBUbyBhbnN3ZXIg QmFyYmFyYeKAmXMgcXVpeiBxdWVzdGlvbiwgaXQgaXMgcG9zc2libGUgdG8gZGVmaW5lIHRoZSBh Y3Rpdml0eSBhcyB0d28gc21hbGwgVGFza3Mgb3Igb25lIGxhcmdlciBpbnRlZ3JhdGVkIFRhc2su DQoNCg0KDQpJIGNhbiB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gdGFsayDigJhob2xpc3RpY2Fs bHnigJkgYWJvdXQgdGhlIHdob2xlIG1lYXN1cmVtZW50IHN5c3RlbS4gQnV0IGxvb2tpbmcgYXQg c2F5IEZpZyBBNCBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxtYXAt ZnJhbWV3b3JrLTA1I3NlY3Rpb24tMTAgVGhlIHBhc3NpdmUgbW9uaXRvciBpcyBhbiBNQSBydW5u aW5nIFBhc3NpdmUgVGFzay4gSXQgb2JzZXJ2ZXMgZXhpc3RpbmcgdHJhZmZpYyBmcm9tIGVudGl0 aWVzIHRoYXQgYXJlLCBmcm9tIGl0cyBwZXJzcGVjdGl2ZSwgTVBzLiBUaGlzIHRyYWZmaWMgY291 bGQgYmUgdXNlciB0cmFmZmljIG9yIGFjdHVhbGx5IGdlbmVyYXRlZCBieSBhbm90aGVyIChBY3Rp dmUpIFRhc2suIEFzIGZhciBhcyB0aGUgZnVuY3Rpb24gbGFiZWxsZWQgUGFzc2l2ZSBNb25pdG9y IGlzIGNvbmNlcm5lZCwgaXQgZG9lc27igJl0IGNhcmUuDQoNCg0KDQpJIHRob3VnaHQgQmFyYmFy YeKAmXMgZXhhbXBsZSBvZiBVRFAgZWNobyBtYWtlcyB0aGUgZ29vZCBwb2ludCB0aGF0IHRoZSBj bGllbnQgYW5kIHNlcnZlciBlbmRzIGhhdmUgYSBkaWZmZXJlbnQgcm9sZSBzbyBtYXkgd2VsbCBo YXZlIHRvIHBvaW50IHRvIGRpZmZlcmVudCByZWdpc3RyeSBlbnRyaWVzLg0KDQoNCg0KSSBhZ3Jl ZSB3aXRoIEFsIHRoYXQgcGFzc2l2ZSBhbmQgYWN0aXZlIGFyZSB0d28gZW5kIHBvaW50cyBvZiBh IGNvbnRpbnV1bSBhbmQgdGhlcmUgYXJlIHRlY2huaXF1ZXMgaW4tYmV0d2VlbiB0aGUgZXh0cmVt ZXMgKGxpa2UgTmFsaW5p4oCZcyBjb2xvdXIgbWFya2luZyBvZiBwa3RzKS4gSeKAmWQgcHJlZmVy IHRvIGxlYXZlIGl0IHRvIGlwcG0gdG8gd29yayBvbiB0aGUgc3VidGxldGllcyDigJMgYXMgZmFy IGFzIGxtYXAgaXMgY29uY2VybmVkIHdlIGtub3cgdGhhdCB0aGVyZeKAmXMgYSByZWdpc3RyeSBv ZiB0ZXN0cywgd2hpY2ggaXBwbSBpcyBwcm9wb3NpbmcgdG8gc3ViLWRpdmlkZSBpbnRvIGFjdGl2 ZSBhbmQgcGFzc2l2ZS4gTWF5YmUgbGF0ZXIgaXBwbSB3aWxsIGRlY2lkZSB3aGljaCBzdWItcmVn aXN0cnkgaW4tYmV0d2VlbiB0ZXN0cyBzaG91bGQgYmUgaW4sIG9yIHRoYXQgYSBuZXcgcmVnaXN0 cnkgaXMgbmVlZGVkLCBvciB3aGF0ZXZlci4gSSB0aGluayBsbWFwIGNhbiBsaXZlIHdpdGggdGhp cyBzbGlnaHQgdW5jZXJ0YWludHkuDQpHSU0+PiBBcyBub3RlZCBpbiBtYWlsIHRvIEp1ZXJnZW4s IExNQVAgRnJhbWV3b3JrIGhhcyB0byB1c2UgTWVhc3VyZW1lbnQgTWV0aG9kLCBhcyB0aGF0IGlz IHdoYXQgYmVpbmcgcmVmZXJlbmNlZCBieSB0aGUgTWVhc3VyZW1lbnQgQ29udHJvbGxlci4gUGVy aGFwcyB3ZSBjYW4gc2h5IGF3YXkgZnJvbSBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiBBY3RpdmUg YW5kIFBhc3NpdmUgbWV0aG9kcy4NCg0KU28gSSB0aGluayBpdOKAmXMgYmV0dGVyIGZvciB0aGUg ZGVmaW5pdGlvbiBvZiBQYXNzaXZlIHRvIHN0aWNrIHdpdGgg4oCcb2JzZXJ2ZXPigJ0uDQoNCg0K DQoNCg0KR3JlZyBkaWRu4oCZdCBsaWtlIHRoZSBmb3JtdWxhdGlvbiDigJxBY3RpdmUgTWVhc3Vy ZW1lbnQgTWV0aG9kIChUYXNrKeKAnSDigJMgaWYgSSByZW1lbWJlciwgaGUgdGhvdWdodCBpdCB3 YXMgdW5jbGVhciBhbmQgd2FudGVkIGl0IHNwbGl0IGludG8gdHdvIGRlZmluaXRpb25zLiBTaW5j ZSB3ZSBhbHJlYWR5IGhhdmUgZGVmaW5pdGlvbnMgZm9yIE1lYXN1cmVtZW50IE1ldGhvZCBhbmQg TWVhc3VyZW1lbnQgVGFzaywgSSBhY3R1YWxseSB0aGluayBpdOKAmXMgdW5uZWNlc3NhcnkgdG8g ZGlzdGluZ3Vpc2ggTWV0aG9kICYgVGFzayBpbiB0aGUgUGFzc2l2ZSAmIEFjdGl2ZSBkZWZpbml0 aW9ucy4gU28gSSBzdWdnZXN0IGRlbGV0aW5nIHRoZSDigJhBY3RpdmUgTWVhc3VyZW1lbnQgTWV0 aG9k4oCZIGRlZmluaXRpb24sIGFuZCBzaW1pbGFybHkgbWFraW5nIHRoZSBQYXNzaXZlIGRlZmlu aXRpb24ganVzdCBhYm91dCDigJhQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2vigJkuDQoNCg0KDQpH cmVnIGFsc28gZGlkbuKAmXQgbGlrZSB0aGUgd2F5IHRoZSBBY3RpdmUgZGVmaW5pdGlvbiB0YWxr cyBhYm91dCBjb29yZGluYXRpb24uIEkgdGhpbmsgdGhlIHBvaW50IGlzOiB3aGlsc3Qgc29tZSBB Y3RpdmUgVGFza3MgaW52b2x2ZSB0aGUgTUEgY29vcmRpbmF0aW5nIHdpdGggb3RoZXIgTVBzIChl eGFtcGxlcyBBMSBhbmQgQTIgaW4gdGhlIEFwcGVuZGl4IOKAkyBlZyB3ZWIgc2VydmVyIHJlc3Bv bmRzIHRvIGNsaWVudCByZXF1ZXN0KSwgaW4gb3RoZXJzIChleGFtcGxlIEEzKSB0aGUgQ29udHJv bGxlciBjb250cm9scyB0aGUgb3RoZXIgTUEgYW5kIHRoZSBmaXJzdCBNQSBqdXN0IHNlbmRzIGl0 IHRyYWZmaWMgKHRoZSBNQXMgZG9u4oCZdCByZWFsbHkgY29vcmRpbmF0ZSB3aXRoIGVhY2ggb3Ro ZXIpLg0KDQoNCg0KLS0NCg0KDQoNClByb3Bvc2FsOi0NCg0KSW4gdGhlIEludHJvLCBhZGQgdG8g dGhlIHBhcmFncmFwaCBhYm91dCBBY3RpdmUgJiBQYXNzaXZlIFRhc2tzOg0KDQpUaGVyZSBtYXkg YWxzbyBiZSBNZWFzdXJlbWVudCBUYXNrcyB0aGF0IGFyZSBpbnRlcm1lZGlhdGUgYmV0d2VlbiBQ YXNzaXZlIGFuZCBBY3RpdmUgb25lczsgY29uc2lkZXJhdGlvbiBpcyBvdXRzaWRlIHRoZSBpbml0 aWFsIExNQVAgd29yayBzY29wZS4NCg0KDQoNCkluIHRlcm1pbm9sb2d5LCB0d2VhayB0aGUgZGVm aW5pdGlvbnM6LQ0KDQpQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFz ayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9ic2VydmVzIGV4aXN0aW5nIHRyYWZmaWMg YnV0IGRvZXMgbm90IGluamVjdCBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYy4NCg0KR0lNPj4g SSB0aGluayB0aGF0ICJvYnNlcnZlcyIgaXMgbm90IHRoZSBzYW1lIGFzICJjb2xsZWN0IGluZm9y bWF0aW9uIG9mZiIuIENhbiBpdCBiZSAiLi4uIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQg Y29sbGVjdHMgaW5mb3JtYXRpb24gb2ZmIGV4aXN0aW5nIHRyYWZmaWMgLi4uIj8gSSB0aGluayB0 aGF0IGEgTWVhc3VyZW1lbnQgQWdlbnQgbWF5IGNvb3JkaW5hdGUgaXRzIGFjdGlvbnMgaW4gcGVy Zm9ybWluZyBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2sgd2l0aCBvdGhlciBNZWFzdXJlbWVudCBB Z2VudHMvUGVlcnMuIE1vcmUgb24gaXQgYmVsb3cuDQoNCkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNr OiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBzZW5kcyBB Y3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0bywgb3IgcmVjZWl2ZXMgaXQgZnJvbSwgb25lIG9y IG1vcmUgb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRzIG9yIE1lYXN1cmVtZW50IFBlZXJzLCBhbmQg cGVyaGFwcyBjb29yZGluYXRlcyB3aXRoIHRoZW0gdXNpbmcgcHJvdG9jb2xzIG91dHNpZGUgdGhl IGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlDQoNCkdJTT4+IElzICJBY3RpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYyIgdGhlIHNhbWUgYXMgIlRlc3QgVHJhZmZpYyI/IEFuZCBJJ2QgbGlrZSB0byBkaXNj dXNzIG5ldyBNZWFzdXJlbWVudCBEb21haW4gb2JqZWN0IGRlZmluZWQgYXM6DQoNClRoZSBjb21t dW5pdHkgb2YgTWVhc3VyZW1lbnQgQWdlbnRzIGFuZCBNZWFzdXJlbWVudCBQZWVycyB0aGF0IGNv b3BlcmF0ZSBpbiBwZXJmb3JtaW5nIGEgTWVhc3VyZW1lbnQgVGFzaywgd2hldGhlciBBY3RpdmUg b3IgUGFzc2l2ZSwgcHJlc2VudCBhIE1lYXN1cmVtZW50IERvbWFpbi4gQ29vcmRpbmF0aW9uIHBy b3RvY29sKHMpIHVzZWQgd2l0aGluIE1lYXN1cmVtZW50IERvbWFpbiBhcmUgb3V0c2lkZSBvZiB0 aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuDQpUaGVuIGluIGRlZmluaXRpb25zIG9mIEFjdGl2 ZS9QYXNzaXZlIE1lYXN1cmVtZW50IFRhc2sgaW4gdGhlIExNQVAgRnJhbWV3b3JrIHdlIGNhbiB1 c2UgdGhlIE1lYXN1cmVtZW50IERvbWFpbiBsaWtlOg0KUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNr OiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBjb2xsZWN0 cyBpbmZvcm1hdGlvbiBvZmYgZXhpc3RpbmcgdHJhZmZpYyB3aXRoaW4gaXRzIE1lYXN1cmVtZW50 IERvbWFpbi4NCg0KDQoNCkJlc3Qgd2lzaGVzDQoNCnBoaWwNCg0KDQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxtYXAgbWFpbGluZyBs aXN0DQpsbWFwQGlldGYub3JnPG1haWx0bzpsbWFwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwDQoNCg== --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2SZXEMA504MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDp ooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hh cg0KCXttc28tc3R5bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj5Qcm9wb3NhbDotPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPkluIHRlcm1pbm9sb2d5LCB0d2VhayB0aGUgZGVmaW5pdGlvbnM6LTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5QYXNzaXZlIE1lYXN1cmVtZW50IFRh c2s6IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9ic2Vy dmVzIGV4aXN0aW5nIHRyYWZmaWMgYnV0IGRvZXMgbm90IGluamVjdCBBY3RpdmUgTWVhc3VyZW1l bnQgVHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+ R0lNJmd0OyZndDsgSSB0aGluayB0aGF0ICZxdW90O29ic2VydmVzJnF1b3Q7IGlzIG5vdCB0aGUg c2FtZSBhcyAmcXVvdDtjb2xsZWN0IGluZm9ybWF0aW9uIG9mZiZxdW90Oy4gQ2FuIGl0IGJlICZx dW90Oy4uLiBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9u IG9mZiBleGlzdGluZyB0cmFmZmljIC4uLiZxdW90Oz8gSSB0aGluayB0aGF0IGEgTWVhc3VyZW1l bnQgQWdlbnQgbWF5IGNvb3JkaW5hdGUgaXRzIGFjdGlvbnMgaW4gcGVyZm9ybWluZw0KIFBhc3Np dmUgTWVhc3VyZW1lbnQgVGFzayB3aXRoIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4g TW9yZSBvbiBpdCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlZlcm8mZ3Q7Jmd0O0kgdGhpbmsgR3JlZ+KAmXMgc3VnZ2VzdGlvbiBvZiB1c2luZyDigJxj b2xsZWN0IGluZm9ybWF0aW9uIG9mZuKAnSBpcyBhIGJldHRlciBpZGVhLiBJdHMgbW9yZSBnZW5l cmljIHRoYW4g4oCcb2JzZXJ2ZXPigJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTi1HQiI+QWN0aXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFz ayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IHNlbmRzIEFjdGl2ZSBNZWFzdXJlbWVudCBU cmFmZmljIHRvLCBvciByZWNlaXZlcyBpdCBmcm9tLCBvbmUgb3IgbW9yZSBvdGhlciBNZWFzdXJl bWVudCBBZ2VudHMgb3IgTWVhc3VyZW1lbnQgUGVlcnMsIGFuZCBwZXJoYXBzIGNvb3JkaW5hdGVz IHdpdGggdGhlbSB1c2luZyBwcm90b2NvbHMNCiBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29y ayBzY29wZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj5HSU0mZ3Q7Jmd0OyBJcyAmcXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJh ZmZpYyZxdW90OyB0aGUgc2FtZSBhcyAmcXVvdDtUZXN0IFRyYWZmaWMmcXVvdDs/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlZlcm8mZ3Q7Jmd0OyB0aGUgY3VycmVudCBkZWZp bml0aW9uIG9mIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljOiAmbmJzcDt0aGUgcGFja2V0KHMp IGdlbmVyYXRlZCBpbiBvcmRlciB0byAmbmJzcDtleGVjdXRlIGFuIEFjdGl2ZSBNZWFzdXJlbWVu dCBUYXNrLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BcyBNYWNoIHBvaW50ZWQgb3V0IGluIGhpcyBub3RlLCB0ZWNobm9sb2dpZXMgbGlrZSBJVFUt VCBZLjE3MzEsIFJGQyA2Mzc0IGFyZSBnZW5lcmF0aW5nIE9BTSBwYWNrZXRzLCB3aGljaCBkZWxp bWl0aW5nIHRoZSBleGlzdGluZyBwYWNrZXRzIGFuZA0KIGNhcnJ5aW5nIHRoZSBpbmZvcm1hdGlv biBvZiBleGlzdGluZyB0cmFmZmljLCBlLmcuIHBhY2tldCBjb3VudHMgYW5kIHRpbWVzdGFtcHMu IFRoZXNlIG1lYXN1cmVtZW50IG1ldGhvZCBnZW5lcmF0ZSBwYWNrZXRzIGluIG9yZGVyIHRvIGV4 ZWN1dGUgYW4gbWVhc3VyZW1lbnQgdGFzaywgYnV0IHdpbGwgeW91IGNvbnNpZGVyIHRoZW0gYXMg QWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZD8gTXkgYW5zd2VyIHdpbGwgYmUgTk8uIEV2ZW4gdGhv dWdoIE9BTQ0KIHBhY2tldHMgaXMgZ2VuZXJhdGVkLCBidXQgdGhlIG1lYXN1cmVtZW50IHRhc2sg aXMgdG8gY29sbGVjdCB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIGV4aXN0aW5nIHRyYWZmaWMsIG5v dCB0aGUgaW5mb3JtYXRpb24gb2YgdGhlIGdlbmVyYXRlZCBwYWNrZXRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIE1hY2ggdGhhdCBpdCdzIGJldHRlciBmcm9t IHRoZSB0ZXN0ZWQgb2JqZWN0IHBvaW50IG9mIHZpZXcgKGUuZy4sIGZvciBhIG1lYXN1cmVtZW50 IHRhc2ssIHdoZXRoZXIgdGhlIHRlc3RlZCBvYmplY3QgaXMgdGhlIGV4aXN0aW5nIHRyYWZmaWMg b3IgaW5qZWN0ZWQgdHJhZmZpYykgdG8gZGVmaW5lIHdoYXQgUGFzc2l2ZQ0KIGFuZCBBY3RpdmUg bWVhc3VyZW1lbnQgbWV0aG9kL3Rhc2svdHJhZmZpYyBpcy4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+SW4gdGhlIEludHJvLCBhZGQgdG8gdGhlIHBhcmFncmFwaCBhYm91 dCBBY3RpdmUgJmFtcDsgUGFzc2l2ZSBUYXNrczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1HQiI+VGhlcmUgbWF5IGFsc28gYmUgTWVhc3VyZW1lbnQgVGFza3MgdGhh dCBhcmUgaW50ZXJtZWRpYXRlIGJldHdlZW4gUGFzc2l2ZSBhbmQgQWN0aXZlIG9uZXM7IGNvbnNp ZGVyYXRpb24gaXMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5WZXJvJmd0OyZndDsgSWYgd2UgdHdl YWsgdGhlIGRlZmluaXRpb25zIGNhcmVmdWxseSwgd2UgbWF5IGRvbuKAmXQgbmVlZCB0byBleGNs dWRlIGFueSBtZWFzdXJlbWVudCB0YXNrcyBvdXRzaWRlIHNjb3BlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsIFZlcm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGxtYXAg W21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWcg TWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgMTozNCBBTTxi cj4NCjxiPlRvOjwvYj4gcGhpbGlwLmVhcmRsZXlAYnQuY29tPGJyPg0KPGI+Q2M6PC9iPiBsbWFw QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gRm9sbG93LXVwIG9uIHJl Y2VudCBkaXNjdXNzaW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj50 aGFuayB5b3UgZm9yIHRoZSBnb29kIGNhcHR1cmUgb2YgbXkgY29tbWVudHMuICZxdW90O0RpZG4n dCBsaWtlJnF1b3Q7IG1heSBiZSBsaXR0bGUgdG9vIHN0cm9uZyB0byBjaGFyYWN0ZXJpemUgbXkg UE9WIGFuZCBzb3JyeSBpZiBpdCBjYW1lIGFjcm9zcyB0aGF0IHdheS4gUGxlYXNlIGZpbmQgbXkg bm90ZXMgaW4tbGluZSBhbmQgdGFnZ2VkIGJ5DQogR0lNJmd0OyZndDsuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBKdW4gMiwgMjAxNCBhdCA4 OjA5IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkZvbGxvd2lu ZyB1cCBvbiB0aGUgdGhyZWFkIChhZnRlciBob2xpZGF5cyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPmN1cnJlbnQgZGVmaW5pdGlvbnM6LTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5QYXNzaXZlIE1lYXN1cmVtZW50IE1ldGhvZCAo VGFzayk6IEEgTWVhc3VyZW1lbnQgTWV0aG9kIChUYXNrKSBpbiB3aGljaCBhIE1lYXN1cmVtZW50 IEFnZW50IG9ic2VydmVzIGV4aXN0aW5nIHRyYWZmaWMgYnV0IGRvZXMgbm90IGluamVjdCBBY3Rp dmUgTWVhc3VyZW1lbnQgVHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hp Y2ggYSBNZWFzdXJlbWVudCBBZ2VudCBjcmVhdGVzIG9yIHJlY2VpdmVzIEFjdGl2ZSBNZWFzdXJl bWVudCBUcmFmZmljLCBieSBjb29yZGluYXRpbmcgd2l0aCBvbmUgb3IgbW9yZSBvdGhlciBNZWFz dXJlbWVudCBBZ2VudHMgb3IgTWVhc3VyZW1lbnQgUGVlcnMgdXNpbmcgcHJvdG9jb2xzIG91dHNp ZGUgdGhlIGluaXRpYWwNCiBMTUFQIHdvcmsgc2NvcGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLUdCIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj5NeSB2aWV3IGlzIHRoYXQgdGhlIFRhc2sgaXMgYWJvdXQgd2hhdCB0aGUgTUEgZG9l cy4gVG8gYW5zd2VyIEJhcmJhcmHigJlzIHF1aXogcXVlc3Rpb24sIGl0IGlzIHBvc3NpYmxlIHRv IGRlZmluZSB0aGUgYWN0aXZpdHkgYXMgdHdvIHNtYWxsIFRhc2tzIG9yIG9uZSBsYXJnZXIgaW50 ZWdyYXRlZCBUYXNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+SSBj YW4gdW5kZXJzdGFuZCB0aGUgZGVzaXJlIHRvIHRhbGsg4oCYaG9saXN0aWNhbGx54oCZIGFib3V0 IHRoZSB3aG9sZSBtZWFzdXJlbWVudCBzeXN0ZW0uIEJ1dCBsb29raW5nIGF0IHNheSBGaWcgQTQg aW4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbG1hcC1m cmFtZXdvcmstMDUjc2VjdGlvbi0xMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNSNzZWN0aW9uLTEwPC9hPiBU aGUgcGFzc2l2ZSBtb25pdG9yIGlzIGFuIE1BIHJ1bm5pbmcgUGFzc2l2ZSBUYXNrLiBJdCBvYnNl cnZlcyBleGlzdGluZyB0cmFmZmljIGZyb20gZW50aXRpZXMgdGhhdCBhcmUsIGZyb20gaXRzIHBl cnNwZWN0aXZlLCBNUHMuIFRoaXMgdHJhZmZpYyBjb3VsZCBiZSB1c2VyIHRyYWZmaWMgb3IgYWN0 dWFsbHkgZ2VuZXJhdGVkDQogYnkgYW5vdGhlciAoQWN0aXZlKSBUYXNrLiBBcyBmYXIgYXMgdGhl IGZ1bmN0aW9uIGxhYmVsbGVkIFBhc3NpdmUgTW9uaXRvciBpcyBjb25jZXJuZWQsIGl0IGRvZXNu 4oCZdCBjYXJlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JIHRo b3VnaHQgQmFyYmFyYeKAmXMgZXhhbXBsZSBvZiBVRFAgZWNobyBtYWtlcyB0aGUgZ29vZCBwb2lu dCB0aGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciBlbmRzIGhhdmUgYSBkaWZmZXJlbnQgcm9sZSBz byBtYXkgd2VsbCBoYXZlIHRvIHBvaW50IHRvIGRpZmZlcmVudCByZWdpc3RyeSBlbnRyaWVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+SSBhZ3JlZSB3aXRoIEFsIHRo YXQgcGFzc2l2ZSBhbmQgYWN0aXZlIGFyZSB0d28gZW5kIHBvaW50cyBvZiBhIGNvbnRpbnV1bSBh bmQgdGhlcmUgYXJlIHRlY2huaXF1ZXMgaW4tYmV0d2VlbiB0aGUgZXh0cmVtZXMgKGxpa2UgTmFs aW5p4oCZcyBjb2xvdXIgbWFya2luZyBvZiBwa3RzKS4gSeKAmWQgcHJlZmVyIHRvIGxlYXZlIGl0 IHRvIGlwcG0gdG8gd29yayBvbiB0aGUgc3VidGxldGllcyDigJMgYXMgZmFyIGFzIGxtYXANCiBp cyBjb25jZXJuZWQgd2Uga25vdyB0aGF0IHRoZXJl4oCZcyBhIHJlZ2lzdHJ5IG9mIHRlc3RzLCB3 aGljaCBpcHBtIGlzIHByb3Bvc2luZyB0byBzdWItZGl2aWRlIGludG8gYWN0aXZlIGFuZCBwYXNz aXZlLiBNYXliZSBsYXRlciBpcHBtIHdpbGwgZGVjaWRlIHdoaWNoIHN1Yi1yZWdpc3RyeSBpbi1i ZXR3ZWVuIHRlc3RzIHNob3VsZCBiZSBpbiwgb3IgdGhhdCBhIG5ldyByZWdpc3RyeSBpcyBuZWVk ZWQsIG9yIHdoYXRldmVyLiBJIHRoaW5rIGxtYXANCiBjYW4gbGl2ZSB3aXRoIHRoaXMgc2xpZ2h0 IHVuY2VydGFpbnR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkdJTSZndDsmZ3Q7IEFz IG5vdGVkIGluIG1haWwgdG8gSnVlcmdlbiwgTE1BUCBGcmFtZXdvcmsgaGFzIHRvIHVzZSBNZWFz dXJlbWVudCBNZXRob2QsIGFzIHRoYXQgaXMgd2hhdCBiZWluZyByZWZlcmVuY2VkIGJ5IHRoZSBN ZWFzdXJlbWVudCBDb250cm9sbGVyLiBQZXJoYXBzIHdlIGNhbiBzaHkgYXdheSBmcm9tIGRpZmZl cmVudGlhdGlvbiBiZXR3ZWVuIEFjdGl2ZSBhbmQgUGFzc2l2ZQ0KIG1ldGhvZHMuJm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PHA+PHNwYW4gbGFuZz0iRU4tR0IiPlNvIEkgdGhpbmsgaXTigJlzIGJldHRlciBmb3IgdGhlIGRl ZmluaXRpb24gb2YgUGFzc2l2ZSB0byBzdGljayB3aXRoIOKAnG9ic2VydmVz4oCdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPkdyZWcgZGlkbuKAmXQgbGlrZSB0aGUgZm9ybXVs YXRpb24g4oCcQWN0aXZlIE1lYXN1cmVtZW50IE1ldGhvZCAoVGFzaynigJ0g4oCTIGlmIEkgcmVt ZW1iZXIsIGhlIHRob3VnaHQgaXQgd2FzIHVuY2xlYXIgYW5kIHdhbnRlZCBpdCBzcGxpdCBpbnRv IHR3byBkZWZpbml0aW9ucy4gU2luY2Ugd2UgYWxyZWFkeSBoYXZlIGRlZmluaXRpb25zIGZvciBN ZWFzdXJlbWVudCBNZXRob2QgYW5kIE1lYXN1cmVtZW50IFRhc2ssIEkgYWN0dWFsbHkNCiB0aGlu ayBpdOKAmXMgdW5uZWNlc3NhcnkgdG8gZGlzdGluZ3Vpc2ggTWV0aG9kICZhbXA7IFRhc2sgaW4g dGhlIFBhc3NpdmUgJmFtcDsgQWN0aXZlIGRlZmluaXRpb25zLiBTbyBJIHN1Z2dlc3QgZGVsZXRp bmcgdGhlIOKAmEFjdGl2ZSBNZWFzdXJlbWVudCBNZXRob2TigJkgZGVmaW5pdGlvbiwgYW5kIHNp bWlsYXJseSBtYWtpbmcgdGhlIFBhc3NpdmUgZGVmaW5pdGlvbiBqdXN0IGFib3V0IOKAmFBhc3Np dmUgTWVhc3VyZW1lbnQgVGFza+KAmS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tR0IiPkdyZWcgYWxzbyBkaWRu4oCZdCBsaWtlIHRoZSB3YXkgdGhlIEFjdGl2ZSBkZWZpbml0 aW9uIHRhbGtzIGFib3V0IGNvb3JkaW5hdGlvbi4gSSB0aGluayB0aGUgcG9pbnQgaXM6IHdoaWxz dCBzb21lIEFjdGl2ZSBUYXNrcyBpbnZvbHZlIHRoZSBNQSBjb29yZGluYXRpbmcgd2l0aCBvdGhl ciBNUHMgKGV4YW1wbGVzIEExIGFuZCBBMiBpbiB0aGUgQXBwZW5kaXgg4oCTIGVnIHdlYiBzZXJ2 ZXIgcmVzcG9uZHMgdG8gY2xpZW50DQogcmVxdWVzdCksIGluIG90aGVycyAoZXhhbXBsZSBBMykg dGhlIENvbnRyb2xsZXIgY29udHJvbHMgdGhlIG90aGVyIE1BIGFuZCB0aGUgZmlyc3QgTUEganVz dCBzZW5kcyBpdCB0cmFmZmljICh0aGUgTUFzIGRvbuKAmXQgcmVhbGx5IGNvb3JkaW5hdGUgd2l0 aCBlYWNoIG90aGVyKS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUdCIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+UHJvcG9zYWw6 LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JbiB0aGUgSW50 cm8sIGFkZCB0byB0aGUgcGFyYWdyYXBoIGFib3V0IEFjdGl2ZSAmYW1wOyBQYXNzaXZlIFRhc2tz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGVyZSBtYXkg YWxzbyBiZSBNZWFzdXJlbWVudCBUYXNrcyB0aGF0IGFyZSBpbnRlcm1lZGlhdGUgYmV0d2VlbiBQ YXNzaXZlIGFuZCBBY3RpdmUgb25lczsgY29uc2lkZXJhdGlvbiBpcyBvdXRzaWRlIHRoZSBpbml0 aWFsIExNQVAgd29yayBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t R0IiPkluIHRlcm1pbm9sb2d5LCB0d2VhayB0aGUgZGVmaW5pdGlvbnM6LTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5QYXNzaXZlIE1lYXN1cmVtZW50IFRhc2s6 IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9ic2VydmVz IGV4aXN0aW5nIHRyYWZmaWMgYnV0IGRvZXMgbm90IGluamVjdCBBY3RpdmUgTWVhc3VyZW1lbnQg VHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+R0lN Jmd0OyZndDsgSSB0aGluayB0aGF0ICZxdW90O29ic2VydmVzJnF1b3Q7IGlzIG5vdCB0aGUgc2Ft ZSBhcyAmcXVvdDtjb2xsZWN0IGluZm9ybWF0aW9uIG9mZiZxdW90Oy4gQ2FuIGl0IGJlICZxdW90 Oy4uLiBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uIG9m ZiBleGlzdGluZyB0cmFmZmljIC4uLiZxdW90Oz8gSSB0aGluayB0aGF0IGEgTWVhc3VyZW1lbnQg QWdlbnQgbWF5IGNvb3JkaW5hdGUgaXRzIGFjdGlvbnMgaW4gcGVyZm9ybWluZw0KIFBhc3NpdmUg TWVhc3VyZW1lbnQgVGFzayB3aXRoIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4gTW9y ZSBvbiBpdCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1H QiI+QWN0aXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3aGljaCBh IE1lYXN1cmVtZW50IEFnZW50IHNlbmRzIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIHRvLCBv ciByZWNlaXZlcyBpdCBmcm9tLCBvbmUgb3IgbW9yZSBvdGhlciBNZWFzdXJlbWVudCBBZ2VudHMg b3IgTWVhc3VyZW1lbnQgUGVlcnMsIGFuZCBwZXJoYXBzIGNvb3JkaW5hdGVzIHdpdGggdGhlbSB1 c2luZyBwcm90b2NvbHMNCiBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+R0lNJmd0OyZndDsgSXMg JnF1b3Q7QWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMmcXVvdDsgdGhlIHNhbWUgYXMgJnF1b3Q7 VGVzdCBUcmFmZmljJnF1b3Q7PyBBbmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1l bnQgRG9tYWluIG9iamVjdCBkZWZpbmVkIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIGNvbW11bml0eSBvZiBNZWFzdXJlbWVudCBBZ2Vu dHMgYW5kIE1lYXN1cmVtZW50IFBlZXJzIHRoYXQgY29vcGVyYXRlIGluIHBlcmZvcm1pbmcgYSBN ZWFzdXJlbWVudCBUYXNrLCB3aGV0aGVyIEFjdGl2ZSBvciBQYXNzaXZlLCBwcmVzZW50IGEgTWVh c3VyZW1lbnQgRG9tYWluLiBDb29yZGluYXRpb24gcHJvdG9jb2wocykgdXNlZCB3aXRoaW4gTWVh c3VyZW1lbnQgRG9tYWluIGFyZSBvdXRzaWRlIG9mDQogdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNj b3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlbiBpbiBkZWZpbml0 aW9ucyBvZiBBY3RpdmUvUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIGluIHRoZSBMTUFQIEZyYW1l d29yayB3ZSBjYW4gdXNlIHRoZSBNZWFzdXJlbWVudCBEb21haW4gbGlrZTo8YnI+DQpQYXNzaXZl IE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3aGljaCBhIE1lYXN1cmVt ZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uIG9mZiBleGlzdGluZyB0cmFmZmljIHdpdGhp biBpdHMgTWVhc3VyZW1lbnQgRG9tYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5CZXN0IHdpc2hlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5waGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KbG1hcCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bG1hcEBpZXRm Lm9yZyI+bG1hcEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xtYXAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2SZXEMA504MBSchi_-- From nobody Wed Jun 4 01:53: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 D99771A0111 for ; Wed, 4 Jun 2014 01:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 6ef8NYkQRj9f for ; Wed, 4 Jun 2014 01:53:20 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C421A011F for ; Wed, 4 Jun 2014 01:53:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoKAMHdjlPGmAcV/2dsb2JhbAA/GoJlIlJYqkIBBAaQUQEchzkBgQ8WdIIlAQEBAQMBAQEPXBcEAgEIDQQEAQEBCh0HAiULFAcBAQUDAgQTCAYUiCABDDaiKbA5F4VViCwBAR44BoMlgRUEkVyBOog4hVmGHQSFfYF4gUBsgQo5 X-IronPort-AV: E=Sophos;i="4.98,972,1392181200"; d="asc'?txt'?scan'208";a="68891577" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2014 04:53:13 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Jun 2014 04:35:13 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 10:53:11 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: [ippm] Second WGLC on draft-ippm-lmap-path was Re: Revised: draft-ietf-ippm-lmap-path-03 Thread-Index: AQHPfns8DHN363gbJk6l+MM+yUBfY5tgp2kQ Date: Wed, 4 Jun 2014 08:53:11 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3@AZ-FFEXMB04.global.avaya.com> References: <2845723087023D4CB5114223779FA9C8017992C829@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/mixed; boundary="_003_9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Nk2VZumGIJA7dLLI5z7WMEVQwvM Subject: [lmap] FW: [ippm] Second WGLC on draft-ippm-lmap-path was Re: Revised: draft-ietf-ippm-lmap-path-03 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:53:22 -0000 --_003_9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please pay attention to this 2nd WGLC in IPPM of on draft-ippm-lmap-path. P= lease send your comments and/or statements of support to the IPPM WG mail l= ist.=20 Regards, Dan > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Monday, June 02, 2014 6:56 PM > To: Al Morton > Cc: ippm@ietf.org > Subject: [ippm] Second WGLC on draft-ippm-lmap-path was Re: Revised: > draft-ietf-ippm-lmap-path-03 >=20 > hi Al, all, >=20 > Thanks for the updated draft! >=20 > The changes appear to be extensive enough that a second WGLC is > warranted; please provide any additional comments (or just a statement th= at > you've read the new doc and it's OK) by Friday, June 13. >=20 > Thanks, >=20 > Brian (as chair) >=20 > On 29 May 2014, at 21:50, MORTON, ALFRED C (AL) > wrote: >=20 > > Hi IPPM, and Lingli, Charles, and Dan in particular: > > > > Thanks for providing comments on this draft during WGLC. > > A version which hopefully addresses all your comments is here: > > http://tools.ietf.org/html/draft-ietf-ippm-lmap-path-03 > > > > It should be fairly easy to find where your comments were addressed, > > using the diff file: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-lmap-path-03.txt > > > > Some changes are fairly extensive, to address Charles' > > request for rules for example. The co-authors had some fun with that > > aspect. > > > > I remember one specific question from Charles, "what is [SK]?" > > it's just a very tight reference to an informative white paper: > > > > [SK] Crawford, Sam., "Test Methodology White Paper", SamKnows > > Whitebox Briefing Note > > http://www.samknows.com/broadband/index.php, July 2011. > > > > regards, > > Al (for the co-authors) > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm --_003_9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3AZFFEXMB04globa_ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail.asc Content-Disposition: attachment; filename="signature.asc"; size=507; creation-date="Mon, 02 Jun 2014 15:56:37 GMT"; modification-date="Mon, 02 Jun 2014 15:56:37 GMT" Content-ID: <0694CD6BB401B44D914E1CA2679FD0EA@avaya.com> Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFFY0JBRUJDZ0FHQlFKVGpKNnNBQW9KRU50M25zT21iTkpjSVdR SC9BeVBuaDVLcXZMUmtqSW43ek5WRmhYRg0KeUxjb0RaRjFvT0ZCdkYvWlhhV1FFU0d1azFON21n dU9vbDVTV09OUWpJTGxYclQzNkJYaGUwaUpxZGE0ZjBqVw0KeE9BeUxZU0JGUVo0L1BSYkJFNkpx emtLQ2NMSnYzTlNZdzJJZUVVZzhYOWl4OVYrMmt5OGdJSVZHQVgvMDlobw0KVzFMMjBjaVZYRjhj dTRDV3hOdmZ2dUVoSWtFOFNXb0R6d3c3UFNLMk56TTdCMzVOeEc4NzVSRWNkZWZ3UXFTYQ0KNlRk R0czMDlGNC90QlErb2xNYXJEQUNxYVdKK2hsVUdnVTJrMElYeWkrc1hsSndpNVM5b3VOS1VRRkVw N2NScA0KbVdGMjJuY1ZqK1Q0eWhzOXJ1UElkZHlQWlZaRXQ3UG82V0NKUXlPWStjWlJkdW5NY1o0 bmFuL1hHU0lMOWdrPQ0KPWxpR0kNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K --_003_9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3AZFFEXMB04globa_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Mon, 02 Jun 2014 15:56:37 GMT"; modification-date="Mon, 02 Jun 2014 15:56:37 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFp bGluZyBsaXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwcG0NCg== --_003_9904FB1B0159DA42B0B887B7FA8119CA5C7FC4E3AZFFEXMB04globa_-- From nobody Wed Jun 4 03:56: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 294C21A016D for ; Wed, 4 Jun 2014 03:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 b5Rz_nLSd9VR for ; Wed, 4 Jun 2014 03:56:37 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D111A0300 for ; Wed, 4 Jun 2014 03:56:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIKAF/6jlPGmAcV/2dsb2JhbABZgmUiUliqQQEEBpgnAYELFnSCJQEBAQEDEigPPAQCAQgNAwEEAQELFAkHMhQJCAIEARIIGoggAQyhd7A3F4VViEw4BoMlgRUElgaFSIVZjB6DOIIv X-IronPort-AV: E=Sophos;i="4.98,972,1392181200"; d="scan'208";a="59198651" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Jun 2014 06:56:28 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Jun 2014 06:38:28 -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; Wed, 4 Jun 2014 12:56:26 +0200 From: "Romascanu, Dan (Dan)" To: "Bajpai, Vaibhav" , "" Thread-Topic: review: draft-bagnulo-lmap-http-01 Thread-Index: AQHPfnfUVxqGYiiiyU+0RkuqmF7GUZtgyYWw Date: Wed, 4 Jun 2014 10:56:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FCC21@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.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/Sp-D53IhoHbT_utdUkVHf2_FRok Subject: Re: [lmap] review: draft-bagnulo-lmap-http-01 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, 04 Jun 2014 10:56:41 -0000 Thank you for your comments, Vaibhav.=20 I notice that this I-D is expired. Maybe the authors plan for an update inc= orporating the comments. In any case, it would be good for the I-D to be re= -submitted, as the WG must do progress soon on the LMAP protocols proposal = (as well as data models) and it's a very good time for such individual subm= issions to be made in order to be considered for discussion before IETF 90.= =20 Regards, Dan > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Bajpai, Vaibhav > Sent: Monday, June 02, 2014 6:32 PM > To: > Cc: Bajpai, Vaibhav > Subject: [lmap] review: draft-bagnulo-lmap-http-01 >=20 > Hello, >=20 > I read the LMAP HTTP protocol document [1] and made some notes. > [1] http://tools.ietf.org/html/draft-bagnulo-lmap-http-01 >=20 > Here is my proposal on how to take this work forward: >=20 > Overview > ~~~~~~~~ >=20 > Once that the MA is deployed it will perform the following operations: >=20 > o After the MA is deployed, it will obtain Instructions from one of > the pre-configured Controllers. These Instructions include > information about the set of measurements to be performed, a > schedule for the execution of the measurements as well as a set of > report channels. This information is downloaded by the MA from > the Controller. The MA will periodically check whether there are > new Instructions available from the Controller. This document > specifies how the MA uses the HTTP protocol to retrieve > information from the Controller. >=20 > According to the information model [draft-ietf-lmap-information-model-00]= . > Before ^, MA also needs to: >=20 > a) Contact the initial controller to retrieve configuration information. >=20 > I personally think it also must send capabilities before asking for instr= uctions. > The controller will bake instructions depending on the received MA > capabilities: >=20 > b) Send MA capabilities over the MA-to-controller channel. >=20 > I can provide a writeup for a) and b) if need be. >=20 > o The MA will execute measurements either by passively listening to > traffic or by actively sending and receiving measurement packets. > How this is done is out of the scope of this document. >=20 > o After one or more measurements have been performed, the MA reports > the results to the Collector. The timing of these uploads is > specified in the measurement Instruction i.e. each measurement > specified in a measurement Instruction contains a report > information, defining when the MA should report the results back > to the Collector. This document specifies how the MA uses the > HTTP protocol to upload the measurement results to the Collector. >=20 > o In addition, the MA will periodically report back to the > Controller information about its capabilities (like the number of > interfaces it has, the corresponding IP addresses, the set of > measurement methods it supports, etc) and also logging information > (whether some of the requested measurement tasks failed and > related information). >=20 > According to the information model [draft-ietf-lmap-information-model-00]= : >=20 > c) The MA also executes task objects that perform logging and status > reporting. These task objects instead send the results over the MA-to- > controller channel. Perhaps, we should merge ^ bullets to state that the > schedule is agnostic to what kind of task is being run. >=20 >=20 > Information Model > ~~~~~~~~~~~~~~~~~ >=20 > The control information (or Instruction) has the following five element= s: >=20 > o The Agent Information element. This contains pointers (URLs) to > the other 4 elements which contain the actual control information. > This serves as a level of indirection allowing the MA to have a > root element from which retrieve all the other elements. >=20 > a) This ^ is the instruction object as per the information model [draft-i= etf- > lmap-information-model-00]. Shall we replace "Agent Information" > with "Instruction Information"? >=20 > o The Set of Measurement Task Configurations: This element defines > the measurements/test that the MA will perform without defining > the schedule when they will be performed. >=20 > o The Set of Report Channels: This element defines the set of > collectors as well as the reporting schedules for the reports. >=20 > b) The MA also performs logging and status reporting that goes over the M= A- > to-controller channel. Perhaps we should replace "report channels" with > "channels" to make this generic that covers all aspects. I also raised th= is issue > in the information model document [draft-ietf-lmap-information-model-00]. >=20 > o The Set of Measurement Schedules for Repeated Tasks: defines the > schedules for the repeated measurements, by referencing the > measurement tasks defined in the second element. > o The Set of Measurement Schedules for Isolated Tasks: defines the > schedules for isolated measurements, again by referencing the > measurement tasks defined in the second element. >=20 > c) The information model [draft-ietf-lmap-information-model-00] does not > distinguish between schedules of isolated and repeated tasks. Perhaps we > should merge these 2 bulleted items and call them measurement schedules? >=20 > d) We are missing discussion on supression object. >=20 > Summary of Report information model here. >=20 > Summary of Status information model here. >=20 > e) This is referred as "capability and status information" in the informa= tion > model [draft-ietf-lmap-information-model-00]. >=20 > Summary of Logging information model here. >=20 > f) This is referred as "MA-to-controller" information in the information = model > [draft-ietf-lmap-information-model-00]. I personally think we should rena= me > the information model section name to logging. >=20 > Summary of Configuration information model here. >=20 > g) This should be discussed before the instruction information model. > h) We are also missing discussion on pre-configuration information. >=20 > Example > ~~~~~~~ >=20 > Once the MA is deployed, it uses the POST method to retrieve the Agent > Information element of the Instruction from the controller as follows >=20 > POST /.well-known/lmap/ma-info/ HTTP/1.1 > Host: controller.example.com > Content-Type: application/lmap-maid+json > Accept: application/lmap-config+json > { > "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479", > } >=20 > a) Within the information model [draft-ietf-lmap-information-model-00], t= his > is a request to fetch the instruction object. I think we should replace > references to "agent information" with "instruction object". Additionally= , the > POST request must be made to the instruction channel target. I think the > .well-known mechanism is only used for registration with the initial > controller. >=20 > As per the information model [draft-ietf-lmap-information-model-00], > before retrieving the instruction object as ^, the MA must do these thing= s: >=20 > b1) Register and retrieve the configuration information (MA ID, instructi= on > channel, and MA-to-controller channel) by sending a POST request with its > device ID to the intial controller embedded in the pre-configured instruc= tion > channel. We are missing this example. >=20 > b2) This registration mechanism must also be idempotent. >=20 > I personally also think, that the MA should send its capabilities before > retrieving the instruction object: >=20 > c) Send MA capabilities over the configured MA-to-controller channel to t= he > controller. The controller will use this information to prepare an instru= ction > object to be sent to the MA on further request. We are missing this examp= le. >=20 > For this particular example, the Agent information returned looks like = this: >=20 > { > "ma-id": "f47ac10b-58cc-4372-a567-0e02b2c3d479", > "version": "1.0", > "measurement-set": "http://controller.example.org > /measurements/", > "report-channel-set": "http://controller.example.org > /channels/", > "repeated-schedule-set": "http://controller.example.org > /schedules/" > "status-set": "http://controller.example.org > /status/" > "logging-set": "http://controller.example.org > /logging/" > } >=20 > According to the information model [draft-ietf-lmap-information-model-00]= : >=20 > a) "measurement-set" should be "ma-tasks" >=20 > b) "report-channel-set" should be "ma-report-channels" (I personally thin= k > this should be ma-channels) >=20 > c) "repeated-schedule-set" should be "ma-schedules" >=20 > d) "status-set" and "logging-set" are part of a) and should be removed. T= he > MA-to-controller channel used to send these objects is sent during > configuration. >=20 > e) We are missing a pointer to "ma-suppression" >=20 >=20 > The first thing that the MA does is to send its status information to > the Controller. this contains information about the MA capabilities > and local configuration, such as interfaces' information and > supported measurement task. For this particular example, the MA > would execute the following method: >=20 > a) I think we should decouple status and capability reporting. Capabiliti= es are > fairly static while status objects need to be periodically reported. I al= so raised > this issue in the information model review [draft-ietf-lmap-information- > model-00]. >=20 > POST /.well-known/lmap/ma-info/ HTTP/1.1 > Host: controller.example.com > Content-Type: application/lmap-maid+json > Accept: application/lmap-config+json > { > "ma-id" : "f47ac10b-58cc-4372-a567-0e02b2c3d479", > "ma-interfaces: [ > {"if-name" : eth0 > "if-type" : ethernetCsmacd > "ip-adddress" :{ > "protocol": v4 > "address": 10.1.1.1 > } > }] > "supported-measurements":[ > {"metric": UDP_Latency}] > } >=20 > b) The ^ example is only sending capabilities. We need an example on how = to > send status objects. >=20 > c) Shouldn't we use a target specified in the MA-to-controller channel to > send capability and status information? The ^ example is sending a POST t= o a > generic .well-known location. >=20 > d) "supported-measurements" according to the information model [draft- > ietf-lmap-information-model-00] is "ma-tasks" >=20 > The MA will next retrieve the set of Instructions from the > Controller. The POST for the Instructions will result in the > following information: >=20 > /s/Instructions/Tasks >=20 >=20 > Transport protocol > ~~~~~~~~~~~~~~~~~~ >=20 > 6.1. Pre-configured information > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o The UUID for the MA. This should be pre-configured so that the > Controller is aware of the MA and can feed configuration > information and measurement Instructions to it. >=20 > a) The information model [draft-ietf-lmap-information-model-00] keeps thi= s > open. The MA UUID can either be pre-configured or provided by the initial > controller during the configuration setup when MA registers a device ID. > Trevor and I discussed this previously, and I think Trevor was hinting to= wards > preferring the latter approach. I also prefer retrieving UUID from the > controller. >=20 > 6.2. Control Protocol > ~~~~~~~~~~~~~~~~~~~~~~ >=20 > The MA uses the Control protocol to retrieve all the resources describe= d > above, namely, the Agent information, the Set of Measurement Task > Configurations, the Set of Report Channels, the Set of Measurement > Schedules > for Repeated Tasks and the Set of Measurement Schedules for Isolated > Tasks. >=20 > a) The information model [draft-ietf-lmap-information-model-00] does not > make a separation between schedules for repeated tasks and isolated tasks= . > It just proposes to use a timing-obj that eventually decides the behavior= of > the schedule. I think we should merge ^ definitions. >=20 >=20 > 6.2.1.1. Using the GET method > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > The frequency for the periodical retrieval is contained in the Agent > Information (???). >=20 > Agent Information retrieval: In order to retrieve the Agent > information the MA uses the HTTP GET method follows: > GET /.well-known/lmap/ma-info/ < ma-iid> HTTP/1.1 > Host: FQDN or IP of the Controller > Accept: application/json (as per [RFC4627]) > The Agent Information should contain the Configuration Retrieval > Schedule (i.e. how often the MA should retrieve configuration > information) and also the Measurement Instruction Retrieval Schedule > (i.e. how often the MA should retrieve the Measurement Instruction > from the Controller). COMMENT: this is missing from the Data Model >=20 > a) The term "Agent Information" is not defined in the information model > [draft-ietf-lmap-information-model-00]. >=20 > b) According to the information model [draft-ietf-lmap-information-model- > 00], > the schedules however are sent as part of the instruction object retrieva= l. >=20 > c) I think RFC 4627 has been recently obsoleted by RFC 7159. >=20 >=20 > 6.2.2. Handling communication failures > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > o The MA will use a timeout for the communication of TIMEOUT > seconds. The value of TIMEOUT MUST be configurable via the > aforementioned Configuration Information retrieval protocol. The > default value for the TIMEOUT is 3 seconds. If after the timeout, > the communication with the Controller has not been established, > the MA will retry doing an exponential backoff and doing a round > robin between the different Controllers it has available. >=20 >=20 > a) In the information model [draft-ietf-lmap-information-model-00], the > instruction channel allows only 1 controller target. The idea of doing a = round- > robin between available controllers on ocassions of TIMEOUT may save the > MA at multiple occassions. Shall we use this concept in the information > model by changing the target to an array? >=20 >=20 > 6.3.1. Handling communication failures > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > If the MA is uploading the report to several Collectors and it > manages to establish the communication before TIMEOUT seconds with at > least one of them, but not with one or more of the other Collectors, > then the MA gives up after TIMEOUT seconds and it MAY issue an alarm. > The definition of how to do that operation is out of the scope of > this document. >=20 > a) What should the MA do when it has results to upload, but cannot contac= t > any collector? The schedule is running and constantly increasing the size= of > the results as the time goes by. When should it decide to drop all collec= ted > results to make sure it doesn't go out of space? >=20 >=20 > Editorial Changes > ~~~~~~~~~~~~~~~~~ >=20 > The reader is referred to the terminology draft for further details. >=20 > a) The terminology draft is merged with the framework draft, no? >=20 > b) [I-D.ietf-lmap-framework] is obsolete > [I-D.burbridge-lmap-information-model] is obsolete. > [I-D.bagnulo-ippm-new-registry-independent] is obsolete. >=20 > o Measurement protocols: These are the protocols used between the MA > and the Measurement Peer in active measurements. These are the > actual packets being used for the measurement operations. >=20 > c) The "measurement protocol" term is not defined in the framework > document. >=20 >=20 > ----------------------------------------------------- > Vaibhav Bajpai >=20 > Research I, Room 86 > Computer Networks and Distributed Systems (CNDS) Lab School of > Engineering and Sciences Jacobs University Bremen, Germany >=20 > www.vaibhavbajpai.com From nobody Wed Jun 4 03:59: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 655111A0328 for ; Wed, 4 Jun 2014 03:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 CFcYptwdS2JF for ; Wed, 4 Jun 2014 03:59:09 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC551A0325 for ; Wed, 4 Jun 2014 03:59:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMKAET7jlPGmAcV/2dsb2JhbAAjJRGCZSJSWKpBAQqYJwGBCxZ0giUBAQEBAxILSx0EAgEIDQQEAQELHQcCMBQHAQEFAwIEEwgGBggGiCABDKFykBECgguZNYRkEwSFVYNeghABgiwOAwEfBhAiAgICgyWBFQSRXIE6gnCLIYwegziBdjk X-IronPort-AV: E=Sophos;i="4.98,972,1392181200"; d="dat'?scan'208";a="68913197" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2014 06:59:01 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Jun 2014 06:41:02 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 12:59:00 +0200 From: "Romascanu, Dan (Dan)" To: "" Thread-Topic: second call: NomCom 2014-2015 Call for Volunteers Thread-Index: AQHPf2CFLtuI7ryEm0yQTIEYwmnL2ZtgyNWg Date: Wed, 4 Jun 2014 10:58:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FCC5A@AZ-FFEXMB04.global.avaya.com> References: <15721.1401823067@sandelman.ca> In-Reply-To: <15721.1401823067@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/mixed; boundary="_002_9904FB1B0159DA42B0B887B7FA8119CA5C7FCC5AAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/MCVy3Y3MbXeimA_rJ_y7gMgjbDw Subject: [lmap] FW: second call: NomCom 2014-2015 Call for Volunteers 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, 04 Jun 2014 10:59:11 -0000 --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7FCC5AAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please consider volunteering for this activity which is of high importance = for the IETF.=20 Thanks and Regards, Dan > -----Original Message----- > From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: Tuesday, June 03, 2014 10:18 PM > To: ietf@ietf.org; WG Chairs > Subject: second call: NomCom 2014-2015 Call for Volunteers >=20 >=20 > The IETF nominating committee (nomcom) process for 2014-15 has begun. > The IETF nomcom appoints folks to fill the open slots on the IAOC, the IA= B, > and the IESG (including IETF Chair). >=20 > This is the second call for volunteers. (and you may have seen it more th= an > once) >=20 > If your name is on the below, then you have volunteered and are qualified= . > If you have heard from me, but are not on the list, then there is some > problem, and you should have gotten a query from me to determine your > eligibility. > If you have volunteered and not heard from him, then please resend; it go= t > lost. >=20 > Ten voting members for the nomcom are selected in a verifiably random way > from a pool of volunteers. The more volunteers, the better chance we have > of choosing a random yet representative cross section of the IETF populat= ion. >=20 > Let's break the 200 volunteer mark again this year! > We are at 54 volunteers so far. >=20 > The details of the operation of the nomcom can be found in RFC 3777, and > BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As specifie= d in > RFC 3777, that means three out of the five past meetings up to the time t= his > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / >=20 > If you qualify, please volunteer. However, much as we want this, before > you > decide to volunteer, please be sure you are willing to forgo appointment = to > any of the positions for which this nomcom is responsible. >=20 > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, are >=20 > IAOC: > To be confirmed >=20 > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler >=20 > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian > Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) = Jari > Arkko (Gen) >=20 > (names with * have publically indicated they will not serve another term) >=20 > The primary activity for this nomcom will begin in July 2014 and should b= e > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) There will > be activities to collect requirements from the community, review candidat= e > questionnaires, review feedback from community members about > candidates, and talk to candidates. >=20 > Thus, being a nomcom member does require some time commitment; but it > is also a very rewarding experience. >=20 > It is very important that you be able to attend IETF91 to conduct intervi= ews. > Being at IETF90 is useful for training. Being at IETF92 is not essential= . >=20 > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours= ) > June 22, 2013, as follows: >=20 > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name: __________-- > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form > Emails: _______________ > [] > > Telephone: _______________________ > // For confirmation if selected >=20 > You should expect an email response from me within 3 business days statin= g > whether or not you are qualified. If you don't receive this response, pl= ease > re-send your email with the tag "RESEND"" added to the subject line. >=20 > If you are not yet sure if you would like to volunteer, please consider t= hat > nomcom members play a very important role in shaping the leadership of th= e > IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ >=20 > I will be publishing a more detailed target timetable, as well as details= of the > randomness seeds to be used for the RFC 3797 selection process, within th= e > next couple weeks. >=20 > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org >=20 > =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by fi= rst name ANM > Zaheduzzaman Sarker Adam Montville Bill VerSteeg Carl Williams Carlos > Martinez Charles Eckel DHRUV DHODY Dacheng Zhang Dapeng Liu Donald > Eastlake Eric VYNCKE Fernando Gont Fred Baker Gonzalo Salgueiro Hongyu Li > Hosnieh Rafiee Hugo Salgado John E Drake John Levine John Scudder Linda > Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Yong Mach Chen > Mark Townsley Matt Lepinski Mehmet Ersue Melinda Shore Min Ye Ning > Zong Ole Troan Pascal Thubert Paul Hoffman Peter Yee Ralph Droms Ron > Bonica Ross Callon Ross Finlayson Sam K. Aldrin Sanjay Mishra Sheng JIANG > Shucheng Liu Stephan Friedl Stephan Wenger Stephen Kent Suhas > Nandakumar Tim Wicinski Tissa Senevirathne Toerless Eckert Wassim Haddad > Xiaohu XU Yuanlong Jiang >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7FCC5AAZFFEXMB04globa_ Content-Type: application/pgp-signature; name="Untitled attachment 00046.dat" Content-Description: Untitled attachment 00046.dat Content-Disposition: attachment; filename="Untitled attachment 00046.dat"; size=491; creation-date="Wed, 04 Jun 2014 10:58:58 GMT"; modification-date="Wed, 04 Jun 2014 10:58:58 GMT" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJVNDRmV0lDTGNQdmQwTjFsQVFJYXJRZitMRmdXcExDY3VtTGRQ MGtwcXIwYlA2eVlub0xqUEhXSw0KdDE0UDZ3Wi8vNWJhdEt3UlI3V09VbHduamU0SEwydzQ4TjBp Mzl5OUtVYVJndVJRT29ZR1VqdGdXMHVDRm9aVQ0KcnoveUF6VzZYNXIyakhDQWNGUFU1TlIrWWFu SXBYWXo5NXo4UmlHL2IrdFFueG1kV0ltdW9RTGJsbWRCNWZzZg0KTS9lZ1ZscTVIOHJZa1FneDZL N3JMRHlhcTFZSWd2Q0MvYjFmd2lmZmlyRjAzZGl3QmJLN054cndpeEk4UTZmLw0KQkJVTEJINnMx dUgzNnpVY0QveE4vd1FqNjMxdjZrM2FGYzhhZm45RXJSNVhEcFdzalRiakpJa2k3ajZxdFlPZg0K RTNXYzhSR1ZKME1UYTBhV2lBbkR0NGlhWlhSUzI5NEJZaWxDVjlYT1I5UDMxSWJ4WFgvbnpRPT0N Cj0vem83DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --_002_9904FB1B0159DA42B0B887B7FA8119CA5C7FCC5AAZFFEXMB04globa_-- From nobody Wed Jun 4 08:34: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 25A451A02DA for ; Wed, 4 Jun 2014 08:34: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 e2U26TBXIadq for ; Wed, 4 Jun 2014 08:34:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5FC1A0381 for ; Wed, 4 Jun 2014 08:34:25 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 4 Jun 2014 16:30:19 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 4 Jun 2014 16:34:12 +0100 From: To: Date: Wed, 4 Jun 2014 16:34:12 +0100 Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+iNv+9NhScaMaSSSB5N3OLHcJQQBfgNyM Message-ID: References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C415EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9oPt-xyohdXVrpFavXd8s3Ht64g Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 15:34:32 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C415EMV67UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Proposal:- In the Intro, add to the paragraph about Active & Passive Tasks: There may also be Measurement Tasks that are intermediate between Passive a= nd Active ones; consideration is outside the initial LMAP work scope. In terminology, tweak the definitions:- Passive Measurement Task: A Measurement Task in which a Measurement Agent o= bserves existing traffic but does not inject Active Measurement Traffic. GIM>> I think that "observes" is not the same as "collect information off".= Can it be "... in which a Measurement Agent collects information off exist= ing traffic ..."? I think that a Measurement Agent may coordinate its actio= ns in performing Passive Measurement Task with other Measurement Agents/Pee= rs. More on it below. [phil] I don't really understand what difference you're getting at - what m= eaning do you want to convey with "collect information" that differs from "= observes"? Active Measurement Task: A Measurement Task in which a Measurement Agent se= nds Active Measurement Traffic to, or receives it from, one or more other M= easurement Agents or Measurement Peers, and perhaps coordinates with them u= sing protocols outside the initial LMAP work scope GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And I'd l= ike to discuss new Measurement Domain object defined as: The community of Measurement Agents and Measurement Peers that cooperate in= performing a Measurement Task, whether Active or Passive, present a Measur= ement Domain. Coordination protocol(s) used within Measurement Domain are o= utside of the initial LMAP work scope. Then in definitions of Active/Passive Measurement Task in the LMAP Framewor= k we can use the Measurement Domain like: Passive Measurement Task: A Measurement Task in which a Measurement Agent c= ollects information off existing traffic within its Measurement Domain. [phil] yes, Active Measurement Traffic is what you could call test traffic = ["Active Measurement Traffic: the packet(s) generated in order to execute a= n Active Measurement Task."] [phil] re measurement domain - i can see this may be a useful concept, but = i don't think we've needed this term yet in lmap. given how tricky agreeing= terminology is, can we delay defining this term until we're sure we need i= t. thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C415EMV67UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

Proposal:-

In the Intro, add to the paragraph about Active & Passive Tasks:<= /u>

There may also be Measurement Tasks that are intermediate between Passiv= e and Active ones; consideration is outside the initial LMAP work scope.=

 

In terminology, tweak the definitions:-

Passive Measurement Task: A Measurement Task in which a Measurement Agen= t observes existing traffic but does not inject Active Measurement Traffic.=

GIM>> I think that "observes" is not the same as "c= ollect information off". Can it be "... in which a Measurement Ag= ent collects information off existing traffic ..."? I think that a Mea= surement Agent may coordinate its actions in performing Passive Measurement Task with other Measurement Agents/Peers. More on it below.

 
[phil] I don't really understand what difference you're getting at - w= hat meaning do you want to convey with "collect information" that= differs from "observes"?


Active Measurement Task: A Measurement Task in which a Measurement Agent= sends Active Measurement Traffic to, or receives it from, one or more othe= r Measurement Agents or Measurement Peers, and perhaps coordinates with the= m using protocols outside the initial LMAP work scope

GIM>> Is "Active Measurement Traffic" the same as "= Test Traffic"? And I'd like to discuss new Measurement Domain object d= efined as: 

The community of Measurement Agents and Measurement Peers that cooperate= in performing a Measurement Task, whether Active or Passive, present a Mea= surement Domain. Coordination protocol(s) used within Measurement Domain ar= e outside of the initial LMAP work scope.

Then in definitions of Active/Passive Measuremen= t Task in the LMAP Framework we can use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent c= ollects information off existing traffic within its Measurement Domain.
 
[phil] yes, Active Measurement Traffic is what y= ou could call test traffic ["Active Measurement Traffic: the packet(s)= generated in order to execute an Active Measurement Task."]
 
[phil] re measurement doma= in - i can see this may be a useful concept, but i don't think we've needed= this term yet in lmap. given how tricky agreeing terminology is, can we de= lay defining this term until we're sure we need it.
 
thanks
phil
--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C415EMV67UKRDdoma_-- From nobody Wed Jun 4 08:38:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB2D1A02F3 for ; Wed, 4 Jun 2014 08:38:25 -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 Y4ymxaLMw8RM for ; Wed, 4 Jun 2014 08:38:22 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094B31A02EB for ; Wed, 4 Jun 2014 08:38:21 -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; Wed, 4 Jun 2014 16:34:15 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 4 Jun 2014 16:38:14 +0100 From: To: , , Date: Wed, 4 Jun 2014 16:37:31 +0100 Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojiBXIBsdgvek+/50hSxhGmp5te9Z7ggAIjHK8= Message-ID: References: , <2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2@SZXEMA504-MBS.china.huawei.com> In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2@SZXEMA504-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C416EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/lkIatUoLAGAKcLSR3HF21magPNM Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 15:38:25 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C416EMV67UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In the Intro, add to the paragraph about Active & Passive Tasks: There may also be Measurement Tasks that are intermediate between Passive a= nd Active ones; consideration is outside the initial LMAP work scope. Vero>> If we tweak the definitions carefully, we may don=92t need to exclud= e any measurement tasks outside scope. [phil] ok, let's shorten to "There may also be Measurement Tasks that are i= ntermediate between Passive and Active ones" --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C416EMV67UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 

In the Intro, add to the paragraph about Active &am= p; Passive Tasks:

There may also be Measurement Tasks that are interm= ediate between Passive and Active ones; consideration is outside the initia= l LMAP work scope.

Vero>> If we tweak = the definitions carefully, we may don=92t need to exclude any measurement t= asks outside scope. 

[phil] ok, let's shorten to "There may also be Measurement Tasks that are intermediate between Passive and Active ones= "

 =

 

--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C416EMV67UKRDdoma_-- From nobody Wed Jun 4 08:54:35 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 56A7F1A0270 for ; Wed, 4 Jun 2014 08:54:34 -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 zwtXIDA7ZbOz for ; Wed, 4 Jun 2014 08:54:32 -0700 (PDT) Received: from nm21-vm4.bullet.mail.ne1.yahoo.com (nm21-vm4.bullet.mail.ne1.yahoo.com [98.138.91.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7F81A0227 for ; Wed, 4 Jun 2014 08:54:32 -0700 (PDT) Received: from [98.138.101.129] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2014 15:54:25 -0000 Received: from [98.138.226.162] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2014 15:54:25 -0000 Received: from [127.0.0.1] by omp1063.mail.ne1.yahoo.com with NNFMP; 04 Jun 2014 15:54:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 735774.11440.bm@omp1063.mail.ne1.yahoo.com Received: (qmail 36118 invoked by uid 60001); 4 Jun 2014 15:54:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401897265; bh=SmF+SOO/Y8E0nyTfmzb4YAjgd7lzRa2zbp14Y0lI5AA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P4P8LaWu14Ad3vOEMglx+sX4aCQvjivBDQ5MMDAs6DijsZkMkdBlFLwfT6NnIjTQIfqqDobK6QvvQWEwPkxkWphA8m7+WSvl6KhlnAXeb/EtDqTskkWglxQe9OdLxzJ0hvhNS8T/EB2YKCqmiuINUwDDH5gst75ddUKbmC87Q9o= X-YMail-OSG: NgtyydMVM1l_y4EXZb.Ydhye8Mv.rKn6._rwthYEKqhOY6x 0NVtrZ0Nl7hVdx_PSGrW0mRlYbdftAUI_TRYNfMQe_cBFAG.mvz1IHE3y4H8 VHBYR9orewyc2b0.mRCYMSrs76QJRMAC0uWA8NAmchdfUK.E8qeNsreKzDSf MLA_hK3i2_wqiK.41ajWGgkmd0wBtp_o7DxEOHzvo6XlfQXe8dpklysZZQYn Fh6qcW6wBNH78ys7WcGrmUsSZABLuURssfuUvXqhl_tKmdlRY9v77A.hCBna wJ9.BG23sCKJGXsxJvs0a7VdDbVwbrZcOdtSQHUInuWr7EE3v4DhnvYj7DhN k1n1qzg34XfZb98YgwGNVk0yzx3PejNkxbGx05sm1CB_MSMMef93kW08vTmJ wFTR9Vvfliol9M2Fy9l.zh.6fN7WOsaPkJBnwwrixAbz6sLpDGYbSXwEfhZB 9lFRlr33otsb.LmQPIk2hPIXmXLKltKahBlkYzgiWWr0w.APj.QkYaZnHQPj gOXKWRmkHgV6Mqq5gbuSbpeB94nzlj78wtvz7apLm5cuEmjLJPUrUJ_J.WTA Rnoub5QXuoPEyYPWA9yKTw7zFzIIlmuJwaB5ovdLb43xzYOOqdTjDZjdaeA5 3GEx6O4y0X80AXAk- Received: from [24.130.37.147] by web125106.mail.ne1.yahoo.com via HTTP; Wed, 04 Jun 2014 08:54:25 PDT X-Rocket-MIMEInfo: 002.001, QlRXLCDCoEkgd2FudGVkIHRvIGdpdmUgeW91IGEgaGVhZHMtdXAgdGhhdCB0aGUgdGVhbSB3aGljaCBoYXMgYmVlbiB3b3JraW5nIG9uIHRoZSBQYXNzaXZlIEZyYW1ld29yayBmb3IgSVBQTSAoZHJhZnQtemhlbmctaXBwbS1mcmFtZXdvcmstcGFzc2l2ZS0wMCkgd2lsbCBiZSBwb3N0aW5nIG91ciBkcmFmdCBvbiBKdW5lIDExdGguCgpXZSB3aWxsIGhhdmUgZGlzY3Vzc2lvbiBhbmQgZGVmaW5pdGlvbiBvZiBtYW55IG9mIHRoZSB0ZXJtcyBpbnZvbHZlZCBpbiBQYXNzaXZlIE1vbml0b3JpbmcgZnJvbSB0aGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.188.663 References: , <2EEA459CD95CCB4988BFAFC0F2287B5C5C846CD2@SZXEMA504-MBS.china.huawei.com> Message-ID: <1401897265.73162.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Wed, 4 Jun 2014 08:54:25 -0700 (PDT) From: Nalini Elkins To: "philip.eardley@bt.com" , "vero.zheng@huawei.com" , "gregimirsky@gmail.com" , "mach.chen@huawei.com" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1552829269-483949487-1401897265=:73162" Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/4gKQm8Ey38XqNYy81jlDz3FyWew Cc: IPPM IETF , "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt 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: Wed, 04 Jun 2014 15:54:34 -0000 --1552829269-483949487-1401897265=:73162 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable BTW, =C2=A0I wanted to give you a heads-up that the team which has been wor= king on the Passive Framework for IPPM (draft-zheng-ippm-framework-passive-= 00) will be posting our draft on June 11th.=0A=0AWe will have discussion an= d definition of many of the terms involved in Passive Monitoring from the I= PPM point of view.=0A=C2=A0=0AThanks,=0A=0ANalini Elkins=0AInside Products,= Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A=0A________________= ________________=0A From: "philip.eardley@bt.com" = =0ATo: vero.zheng@huawei.com; gregimirsky@gmail.com; mach.chen@huawei.com = =0ACc: lmap@ietf.org =0ASent: Wednesday, June 4, 2014 8:37 AM=0ASubject: Re= : [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.= txt=0A =0A=0A=0A=C2=A0=0AIn the Intro, add to the paragraph about Active & = Passive Tasks:=0AThere may also be Measurement Tasks that are intermediate = between Passive and Active ones; consideration is outside the initial LMAP = work scope.=0AVero>> If we tweak the definitions carefully, we may don=E2= =80=99t need to exclude any measurement tasks outside scope.=0A=C2=A0=0A[ph= il] ok, let's shorten to "There may also be Measurement Tasks that are inte= rmediate between Passive and Active ones"=0A=C2=A0=0A=C2=A0=0A=0A__________= _____________________________________=0Almap mailing list=0Almap@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/lmap --1552829269-483949487-1401897265=:73162 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
BTW,  I wanted t= o give you a heads-up that the team which has been working on the Passive F= ramework for IPPM (draft-zheng-ippm-framework-passive-00) will be posting o= ur draft on June 11th.

We will have disc= ussion and definition of many of the terms involved in Passive Monitoring f= rom the IPPM point of view.
 
Th= anks,

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

From: "philip.eardley= @bt.com" <philip.eardley@bt.com>
To: vero.zheng@huawei.com; gregimirsky@gmail.com; mach.che= n@huawei.com
Cc: lmap@= ietf.org
Sent: Wednes= day, June 4, 2014 8:37 AM
Subject= : Re: [lmap] Follow-up on recent discussion about draft-ietf-lma= p-framework-05.txt

=0A=0A
 
=0A=
=0A
=0A
In the Intro, add to the paragraph about Active & Passive Tasks:
=0A
There may also be Measurement Tasks t= hat are intermediate between Passive and Active ones; consideration is outs= ide the initial LMAP work scope.
=0A
Vero>> If we tweak the d= efinitions carefully, we may don=E2=80=99t need to exclude any measurement = tasks outside scope.
= =0A
=  
=0A
[phil] ok, let's short= en to "There may also=0A be Measurement Tasks that are intermediate between Pa= ssive and Active ones"
=0A
&n= bsp;
=0A
 
=0A
=0A
=0A
=0A

_______________________= ________________________
lmap mailing list
lmap@ietf.org
https://www.ietf= .org/mailman/listinfo/lmap


--1552829269-483949487-1401897265=:73162-- From nobody Wed Jun 4 08:59:50 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 3D9A91A0387 for ; Wed, 4 Jun 2014 08:59:44 -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 IztszBzYRPSt for ; Wed, 4 Jun 2014 08:59:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228AF1A0369 for ; Wed, 4 Jun 2014 08:59:41 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 4 Jun 2014 16:59:40 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 4 Jun 2014 16:59:34 +0100 From: To: Date: Wed, 4 Jun 2014 16:59:34 +0100 Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+c1IuW/beYBhwTt+OiwOS2H6N3AAfK65AAAAEd0AARwjYiQ== Message-ID: References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/htxGESFAGcNpuKFf-H3FKsH-ioo Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 15:59:44 -0000 > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. Given that there are some existing passive measurement solutions (e.g., Y.1= 731, RFC6374 (direct mode)) that may inject extra traffic to help measuring= , I am not sure whether "does not inject Active Measurement Traffic" is sti= ll one of the characteristics of Passive Measurement. IMHO, it's better fro= m the tested object point of view (e.g., for a measurement task, whether th= e tested object is the existing traffic or injected traffic) to describe wh= at is Passive and Active measurement. [phil] so i think this means your proposal is that we define: Active - meas= ure injected traffic. Passive =3D measure existing traffic (may or may not= inject traffic) i come back to Al's comment. there are pure passive tests, there are pure a= ctive ones. there are hybrid ones, which lmap hasn't thought too much about= . all lmap cares about is that a test will be defined by a registry; ippm s= ubdivide this registry into active and passive, so it's their job to decide= which side of the line different hybrid tests sit.=20 my opinion is that we shouldn't worry about these hybrid tests. [phil] my opinion is that it isn't worth further agonising over the definit= ion of Passive vs Active. (btw, i disagree with your proposed definitions). i suggest we should either go with the definitions we've got, or we should = delete the active/passive definitions and do some small re-write so it isn'= t needed (particularly in the privacy section) phil= From nobody Wed Jun 4 09:24: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 814481A02E2 for ; Wed, 4 Jun 2014 09:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 sg119bhpC16Z for ; Wed, 4 Jun 2014 09:24:21 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DF1A028D for ; Wed, 4 Jun 2014 09:24:21 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4960A0A79; Wed, 4 Jun 2014 12:24:14 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.8]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 82765A0A66; Wed, 4 Jun 2014 12:24:14 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.233]) by SPQCCAS01.exfo.com ([10.28.36.8]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 12:24:14 -0400 From: Sharam Hakimi To: "philip.eardley@bt.com" , "mach.chen@huawei.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+c1IuqgnM+AWbVECOrLtb09ysDAAfK65AAAAEd0AAT9upAAAIBpXA Date: Wed, 4 Jun 2014 16:24:12 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7058A41@SPQCMBX01.exfo.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.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-20736.007 X-TM-AS-Result: No--13.432-5.0-31-10 X-imss-scan-details: No--13.432-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20736.007 X-TMASE-Result: 10--13.432400-5.000000 X-TMASE-MatchedRID: vEvJ7Rh1lGj0GGSQQaBfEe/uue7xcpjDt3aeg7g/usBR6SMusLeVMFfe kLFvP8UVqKpParhRmXtdmS5N/GIG10lZOTqttGG5r04R126Gsietd43bsQ5dArV5fSMRD1zqSrJ WqEROT22mq2Q00sW8KdkVAVb359lcvXtlm87JVdoTRDzcDa8P6weCHewokHM/70m3PKqB7tFWFh mPLWym/pnx/Ba3kGFgBwBqYIq+wVzZFZgMSVeSFvT+KclxuHvf0ZujfvihvDBXJyCkmYopdy4su uEQr3gG5NBvEMa3vVWdpxwiiqhnWLvmZwuacsI7wR3oBUcW2mO7nrAU9KQxUUklF5L0lQHccTM6 +ICWJVfJI6UKM89L2Ia4OO9ykHle717yJ8IcCttCvapcIkxJX3WT6A/Vdqa0myiLZetSf8l9j2G wzTE3vSq2rl3dzGQ1bvsoMHHm4YgsT0sMQUEUHKpRA66u54E+132EXF3pEPb84Qk6eStI9A== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/vmr__gzLHrq-aYCuG1MawEIMTFE Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 16:24:23 -0000 Phil, A couple of points, 1) I do not think ACTIVE in "inject Active Measurement Traffic" is necessar= y. I suggest to change it to "inject Measurement Traffic" 2) For Passive I think if we change OBSERVE in " A Measurement Task in whi= ch a Measurement Agent > observes existing traffic" to "Collects" that it would resolve the issue.= Even to observe, one has to collect first before observing. The rest of wh= at is done after collection of traffic from the network is out of scope of = LMAP. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Wednesday, June 04, 2014 12:00 PM To: mach.chen@huawei.com Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-fr= amework-05.txt > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. Given that there are some existing passive measurement solutions (e.g., Y.1= 731, RFC6374 (direct mode)) that may inject extra traffic to help measuring= , I am not sure whether "does not inject Active Measurement Traffic" is sti= ll one of the characteristics of Passive Measurement. IMHO, it's better fro= m the tested object point of view (e.g., for a measurement task, whether th= e tested object is the existing traffic or injected traffic) to describe wh= at is Passive and Active measurement. [phil] so i think this means your proposal is that we define: Active - meas= ure injected traffic. Passive =3D measure existing traffic (may or may not= inject traffic) i come back to Al's comment. there are pure passive tests, there are pure a= ctive ones. there are hybrid ones, which lmap hasn't thought too much about= . all lmap cares about is that a test will be defined by a registry; ippm s= ubdivide this registry into active and passive, so it's their job to decide= which side of the line different hybrid tests sit.=20 my opinion is that we shouldn't worry about these hybrid tests. [phil] my opinion is that it isn't worth further agonising over the definit= ion of Passive vs Active. (btw, i disagree with your proposed definitions). i suggest we should either go with the definitions we've got, or we should = delete the active/passive definitions and do some small re-write so it isn'= t needed (particularly in the privacy section) phil _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Jun 4 09:40: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 C247D1A0312 for ; Wed, 4 Jun 2014 09:40:39 -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 RKfr-8rtHObf for ; Wed, 4 Jun 2014 09:40:38 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3B11A03CA for ; Wed, 4 Jun 2014 09:40:28 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so9206946veb.10 for ; Wed, 04 Jun 2014 09:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CDC+oeR5WWAPQF9E1Ye3uMCK0MCUEIfwQjVBQN5hgSg=; b=tx+I8DO/edtHVF4dIuGpLYzbQtP59N5z7kihtakTnKD5lSigdoehmeX5+cfAhfoT3S 0tL0W547rh67zLiFw/Eg4wFQnZI7g7puCvkD91gZ/1KoBK9G3LTYjgEDjL5DFQA2181C n9Bt/jgNk4G/fIMK54gp2xj+JrDONmdjj8CZJ3ExG72I99Fvo+JylEoYaEiOwcKu0Yht 7yfqjLuzdnoEFpDlFqBNwmera5TVUvnwV3bGLMJZcDhvA6LdgpIk2+Atzzeh1/fZKAhM SoynEHByrZ20V/OuGfUaKKybQ2+5c1WYyLrtrgcEEQTqcS/kDP6FBmQ0wkfL0n//BBj1 tRVQ== MIME-Version: 1.0 X-Received: by 10.58.136.168 with SMTP id qb8mr45033158veb.21.1401900022215; Wed, 04 Jun 2014 09:40:22 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Wed, 4 Jun 2014 09:40:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jun 2014 09:40:22 -0700 Message-ID: From: Greg Mirsky To: "philip.eardley@bt.com" Content-Type: multipart/alternative; boundary=047d7b5d3110d5bc9604fb054840 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5k9lonSOrSLJrY3WXy2vQN9GCdI Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 16:40:40 -0000 --047d7b5d3110d5bc9604fb054840 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, thank you for your prompt response to my comments. if I compare common interpretations of "observe" and "collect": ob=C2=B7serve* verb* \=C9=99b-=CB=88z=C9=99rv\ : to watch and sometimes also listen to (someone or something) carefully : to see and notice (someone or something) : to make a comment about something you notice vs. col=C2=B7lect* verb* \k=C9=99-=CB=88lekt\ : to get (things) from different places and bring them together : to get (one or more things) from a place : to get (similar things) and bring them together as a hobby the latter seems as more suitable in characterization of role of MA(s) in executing Passive Measurement methods. RE: Measurement Domain. Given earlier discussion and suggestion to take holistic approach to MA/MP role, I believe we are at the point where discussion of Measurement Domain's definition and use is timely and appropriate. Regards, Greg On Wed, Jun 4, 2014 at 8:34 AM, wrote: > > >> Proposal:- >> >> In the Intro, add to the paragraph about Active & Passive Tasks: >> >> There may also be Measurement Tasks that are intermediate between Passiv= e >> and Active ones; consideration is outside the initial LMAP work scope. >> >> >> >> In terminology, tweak the definitions:- >> >> Passive Measurement Task: A Measurement Task in which a Measurement Agen= t >> observes existing traffic but does not inject Active Measurement Traffic= . >> >> GIM>> I think that "observes" is not the same as "collect information >> off". Can it be "... in which a Measurement Agent collects information o= ff >> existing traffic ..."? I think that a Measurement Agent may coordinate i= ts >> actions in performing Passive Measurement Task with other Measurement >> Agents/Peers. More on it below. >> >> [phil] I don't really understand what difference you're getting at - wha= t >> meaning do you want to convey with "collect information" that differs fr= om >> "observes"? >> >> >> Active Measurement Task: A Measurement Task in which a Measurement >> Agent sends Active Measurement Traffic to, or receives it from, one or m= ore >> other Measurement Agents or Measurement Peers, and perhaps coordinates w= ith >> them using protocols outside the initial LMAP work scope >> > GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And >> I'd like to discuss new Measurement Domain object defined as: >> > The community of Measurement Agents and Measurement Peers that >> cooperate in performing a Measurement Task, whether Active or Passive, >> present a Measurement Domain. Coordination protocol(s) used within >> Measurement Domain are outside of the initial LMAP work scope. >> > Then in definitions of Active/Passive Measurement Task in the LMAP > Framework we can use the Measurement Domain like: > Passive Measurement Task: A Measurement Task in which a Measurement Agent > collects information off existing traffic within its Measurement Domain. > > [phil] yes, Active Measurement Traffic is what you could call test > traffic ["Active Measurement Traffic: the packet(s) generated in order > to execute an Active Measurement Task."] > > [phil] re measurement domain - i can see this may be a useful concept, bu= t > i don't think we've needed this term yet in lmap. given how tricky agreei= ng > terminology is, can we delay defining this term until we're sure we need = it. > > thanks > phil > --047d7b5d3110d5bc9604fb054840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
thank you for y= our prompt response to my comments.
if I compare common interpreta= tions of "observe" and "collect":

ob=C2=B7serve v= erb \=C9=99b-=CB=88z= =C9=99rv\ =20 =20

: to watch and s= ometimes also listen to (someone or something) carefully

: to see and= notice (someone or something)

: to make a comment about s= omething you notice

vs.

col=C2=B7lect verb \k=C9=99-=CB=88lekt\ = =20 =20

: to get (things= ) from different places and bring them together

: to get (one or more= things) from a place

: to get (similar things) and bring = them together as a hobby

the latter = seems as more suitable in characterization of role of MA(s) in executing Pa= ssive Measurement methods.
RE: Measurement Domain. Given earlier d= iscussion and suggestion to take holistic approach to MA/MP role, I believe= we are at the point where discussion of Measurement Domain's definitio= n and use is timely and appropriate.

Regards,
Greg

On Wed, Jun 4, 2014 at 8:34 AM, <philip.= eardley@bt.com> wrote:
=C2=A0

Proposal:-

In the Intro, add to the paragraph about Active & Passive Tasks:<= /u>

There may also be Measurement Tasks that are intermediate between Passiv= e and Active ones; consideration is outside the initial LMAP work scope.=

=C2=A0

In terminology, tweak the definitions:-

Passive Measurement Task: A Measurement Task in which a Measurement Agen= t observes existing traffic but does not inject Active Measurement Traffic.=

GIM>> I think that "observes" is not the same as "c= ollect information off". Can it be "... in which a Measurement Ag= ent collects information off existing traffic ..."? I think that a Mea= surement Agent may coordinate its actions in performing Passive Measurement Task with other Measurement Agents/Peers. More on it below.

=C2=A0
[phil] I don't really understand what difference you're = getting at - what meaning do you want to convey with "collect informat= ion" that differs from "observes"?


Active Measurement Task: A Measurement Task in which a Measurement Agent= sends Active Measurement Traffic to, or receives it from, one or more othe= r Measurement Agents or Measurement Peers, and perhaps coordinates with the= m using protocols outside the initial LMAP work scope

GIM>> Is "Active Measurement Traffic" the same as "= Test Traffic"? And I'd like to discuss new Measurement Domain obje= ct defined as:=C2=A0

The community of Measurement Agents and Measurement Peers that cooperate= in performing a Measurement Task, whether Active or Passive, present a Mea= surement Domain. Coordination protocol(s) used within Measurement Domain ar= e outside of the initial LMAP work scope.

Then in definitions of Active/Passive Measuremen= t Task in the LMAP Framework we can use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent c= ollects information off existing traffic within its Measurement Domain.
=C2=A0
[phil] yes, Active Measurement Traffic is what y= ou could call test traffic ["Active Measurement Traffic: the packet(s)= generated in order to=C2=A0execute an Active Measurement Task."]
=C2=A0
[phil] re measurement doma= in - i can see this may be a useful concept, but i don't think we'v= e needed this term yet in lmap. given how tricky agreeing terminology is, c= an we delay defining this term until we're sure we need it.
=C2=A0
thanks
phil

--047d7b5d3110d5bc9604fb054840-- From nobody Wed Jun 4 16:07: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 9AFCF1A0394 for ; Wed, 4 Jun 2014 16:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 U3H9pThTYWmZ for ; Wed, 4 Jun 2014 16:07:33 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DB41A038B for ; Wed, 4 Jun 2014 16:07:33 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id fa6af835.2ab7f0c2d940.29441.00-561.74994.p01c12o147.mxlogic.net (envelope-from ); Wed, 04 Jun 2014 17:07:27 -0600 (MDT) X-MXL-Hash: 538fa6af19125673-a510fe368515d93519374699185d67c47ef476a6 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 4b5af835.0.27884.00-381.71186.p01c12o147.mxlogic.net (envelope-from ); Wed, 04 Jun 2014 17:03:17 -0600 (MDT) X-MXL-Hash: 538fa5b519cdf7b7-e04a3a16d66626b01c50df0f504cd4e31e92fb2e Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 18:03:15 -0500 From: KEN KO To: Greg Mirsky , "philip.eardley@bt.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojf/1VECZMV+0q/TqGdomu4/5tha54AgAASfACAAAsT0A== Date: Wed, 4 Jun 2014 23:03:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.179.34] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756DA4Dexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=U5IcDIbu c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=zQWUatPvp80A:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=FFz51ONUF08A:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=e9qsufxtAAAA:8 a=U4qd5kkuD5526ExJONQA:9 a=qer4aw6k2k3E] X-AnalysisOut: [adM-:21 a=IiZBdsDoA6WEF3Hm:21 a=QEXdDO2ut3YA:10 a=lZB815dz] X-AnalysisOut: [VvQA:10 a=W1qU_X6G3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:] X-AnalysisOut: [8 a=jIgHS3OXIg2SeyJCNDsA:9 a=0y1UGN6EhNdbI2_q:21 a=-5GPulF] X-AnalysisOut: [V9kS82WWR:21 a=xeuBNIM20ZRT4iPV:21 a=gKO2Hq4RSVkA:10 a=UiC] X-AnalysisOut: [Q7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliw] X-AnalysisOut: [V7b4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060428); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/SBfy9XELajP32JemNDDlC139W3s Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.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, 04 Jun 2014 23:07:36 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756DA4Dexmb1corpadtran_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSByZWFkIHRoaXMgZW1haWwgdGhyZWFkIHdoaWNoIGlzIHNpbWlsYXIgdG8gZWFybGllciBv bmVzIGRpc2N1c3NpbmcgYWN0aXZlIHZzLiBwYXNzaXZlLCBJIGtlZXAgdGhpbmtpbmcgYWJvdXQg dGhlIG9ubHkgcGxhY2UgdGhlIGRpc3RpbmN0aW9uIGlzIGJlaW5nIHVzZWQgaW4gdGhlIGxtYXAg ZnJhbWV3b3JrLCB3aGljaCBpcyBmb3Igc3VwcHJlc3Npb24uIEFuZCwgSSBrZWVwIHRoaW5raW5n IHRoYXQgd2UgYXJlIGNyZWF0aW5nIGEgZGlzdGluY3Rpb24gdGhlIGRldGFpbHMgb2Ygd2hpY2gg d2UgY2Fubm90IGFncmVlIG9uLCBhbmQgdGhhdCBkaWZmZXJlbnQgdGVzdCBzeXN0ZW0gb3BlcmF0 b3JzICBpbnRlbmQgdG8gdXNlIGluIGRpZmZlcmVudCB3YXlzLiBBbmQgdGhpcyBsZWFkcyBtZSB0 byB0aGluayB0aGF0IHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBwcm92aWRlIHRoZSBhZ3JlZWQg c3VwcHJlc3Npb24gYmVoYXZpb3Igd2hpbGUgYWxsb3dpbmcgdGVzdCBzeXN0ZW0gb3BlcmF0b3Jz IHRvIG1vZGlmeSBpdCBhcyB0aGV5IHdpc2guDQoNCkRlZmF1bHQgc3VwcHJlc3Npb24gYmVoYXZp b3IsIGFzIHNwZWNpZmllZCBpbiBmcmFtZXdvcmstMDU6DQoNCuKAnFN1cHByZXNzaW9uIG1lYW5z IHRoYXQgdGhlIE1BIGRvZXMgbm90IGJlZ2luIGFueSBuZXcNCkFjdGl2ZSBNZWFzdXJlbWVudCBU YXNrLiBUaGUgaW1wYWN0IG9uIG90aGVyIE1lYXN1cmVtZW50IFRhc2tzIGlzDQpub3QgZGVmaW5l ZCBieSBMTUFQOyBzaW5jZSB0aGV5IGRvIG5vdCBpbnZvbHZlIHRoZSBNQSBjcmVhdGluZyBhbnkN CkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3VwcHJlc3Mg dGhlbSwgaG93ZXZlcg0KaXQgbWF5IGJlIHNpbXBsZXIgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRv IGRvIHNvLuKAnQ0KDQpXZSBoYXZlIGFycml2ZWQgYXQgdGhpcyBwb2ludCBiZWNhdXNlIHN0YWtl aG9sZGVycyBjb3VsZCBub3QgYWdyZWUgb24gaG93IHRvIHRyZWF0IFBhc3NpdmUgVGFza3MuIEFz IGEgcmVzdWx0LCBzb21lIG9wZXJhdG9ycyBtYXkgc3VwcHJlc3MgUGFzc2l2ZSBUYXNrcyBieSBk ZWZhdWx0IGFuZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVlLCB3aXRoIHZhcmlhdGlvbnMg YmV0d2VlbiB0aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNpbmNlIHdlIGFyZSBzdGlsbCBk ZWJhdGluZyB3aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4gQWN0aXZlIGFuZCBQYXNzaXZl LCB0aGUgbWF0dGVyIGlzIG5vdCBzZXR0bGVkLg0KDQpUaGVyZSBpcyBhIGJldHRlciB3YXkuIFNp bXBseSBhZGQgYSBmaWVsZCDigJMgYSBCb29sZWFuIHRydWUvZmFsc2UgZmxhZyBpcyBhbGwgdGhh dCBpcyByZXF1aXJlZCDigJMgdG8gdGhlIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJhdGlvbiBp bmRpY2F0aW5nIHdoZXRoZXIgdGhhdCBUYXNrIGlzIHRvIGJlIHN1cHByZXNzZWQgYnkgZGVmYXVs dC4gSXQgc2hvcnRjdXRzIHRoZSBBY3RpdmUgUGFzc2l2ZSBhcmd1bWVudHMgKGF0IGxlYXN0LCBp biBsbWFwKSBhbmQgZ2l2ZXMgb3BlcmF0b3JzIGNvbXBsZXRlIGZyZWVkb20gb3ZlciBkZWZhdWx0 IHN1cHByZXNzaW9uIGJlaGF2aW9yLg0KDQpUaGUgZGVzY3JpcHRpb24gb2YgYSBNZWFzdXJlbWVu dCBNZXRob2QgaW4gYSByZWdpc3RyeSBjb3VsZCBjb250YWluIGEgcmVjb21tZW5kZWQgdmFsdWUg Zm9yIHRoZSBmbGFnLiBIb3dldmVyLCBvcGVyYXRvcnMgd291bGQgYmUgZnJlZSB0byB1c2UgdGhh dCB2YWx1ZSBvciBvdmVycmlkZSBpdCBpbiB0aGVpciBkZXBsb3ltZW50cy4NCg0KQ29tbWVudHM/ DQoNCktlbg0KDQoNCkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDEw OjQwIEFNDQpUbzogcGhpbGlwLmVhcmRsZXlAYnQuY29tDQpDYzogbG1hcEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtsbWFwXSBGb2xsb3ctdXAgb24gcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgZHJh ZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCg0KSGkgUGhpbCwNCnRoYW5rIHlvdSBmb3Ig eW91ciBwcm9tcHQgcmVzcG9uc2UgdG8gbXkgY29tbWVudHMuDQppZiBJIGNvbXBhcmUgY29tbW9u IGludGVycHJldGF0aW9ucyBvZiAib2JzZXJ2ZSIgYW5kICJjb2xsZWN0IjoNCm9iwrdzZXJ2ZSB2 ZXJiIFzJmWIty4h6yZlydlwNCg0KOiB0byB3YXRjaCBhbmQgc29tZXRpbWVzIGFsc28gbGlzdGVu IHRvIChzb21lb25lIG9yIHNvbWV0aGluZykgY2FyZWZ1bGx5DQoNCjogdG8gc2VlIGFuZCBub3Rp Y2UgKHNvbWVvbmUgb3Igc29tZXRoaW5nKQ0KOiB0byBtYWtlIGEgY29tbWVudCBhYm91dCBzb21l dGhpbmcgeW91IG5vdGljZQ0KdnMuDQpjb2zCt2xlY3QgdmVyYiBca8mZLcuIbGVrdFwNCg0KOiB0 byBnZXQgKHRoaW5ncykgZnJvbSBkaWZmZXJlbnQgcGxhY2VzIGFuZCBicmluZyB0aGVtIHRvZ2V0 aGVyDQoNCjogdG8gZ2V0IChvbmUgb3IgbW9yZSB0aGluZ3MpIGZyb20gYSBwbGFjZQ0KOiB0byBn ZXQgKHNpbWlsYXIgdGhpbmdzKSBhbmQgYnJpbmcgdGhlbSB0b2dldGhlciBhcyBhIGhvYmJ5DQp0 aGUgbGF0dGVyIHNlZW1zIGFzIG1vcmUgc3VpdGFibGUgaW4gY2hhcmFjdGVyaXphdGlvbiBvZiBy b2xlIG9mIE1BKHMpIGluIGV4ZWN1dGluZyBQYXNzaXZlIE1lYXN1cmVtZW50IG1ldGhvZHMuDQpS RTogTWVhc3VyZW1lbnQgRG9tYWluLiBHaXZlbiBlYXJsaWVyIGRpc2N1c3Npb24gYW5kIHN1Z2dl c3Rpb24gdG8gdGFrZSBob2xpc3RpYyBhcHByb2FjaCB0byBNQS9NUCByb2xlLCBJIGJlbGlldmUg d2UgYXJlIGF0IHRoZSBwb2ludCB3aGVyZSBkaXNjdXNzaW9uIG9mIE1lYXN1cmVtZW50IERvbWFp bidzIGRlZmluaXRpb24gYW5kIHVzZSBpcyB0aW1lbHkgYW5kIGFwcHJvcHJpYXRlLg0KUmVnYXJk cywNCkdyZWcNCg0KT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA4OjM0IEFNLCA8cGhpbGlwLmVhcmRs ZXlAYnQuY29tPG1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+PiB3cm90ZToNCg0KDQpQcm9w b3NhbDotDQoNCkluIHRoZSBJbnRybywgYWRkIHRvIHRoZSBwYXJhZ3JhcGggYWJvdXQgQWN0aXZl ICYgUGFzc2l2ZSBUYXNrczoNCg0KVGhlcmUgbWF5IGFsc28gYmUgTWVhc3VyZW1lbnQgVGFza3Mg dGhhdCBhcmUgaW50ZXJtZWRpYXRlIGJldHdlZW4gUGFzc2l2ZSBhbmQgQWN0aXZlIG9uZXM7IGNv bnNpZGVyYXRpb24gaXMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuDQoNCg0K DQpJbiB0ZXJtaW5vbG9neSwgdHdlYWsgdGhlIGRlZmluaXRpb25zOi0NCg0KUGFzc2l2ZSBNZWFz dXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBB Z2VudCBvYnNlcnZlcyBleGlzdGluZyB0cmFmZmljIGJ1dCBkb2VzIG5vdCBpbmplY3QgQWN0aXZl IE1lYXN1cmVtZW50IFRyYWZmaWMuDQoNCkdJTT4+IEkgdGhpbmsgdGhhdCAib2JzZXJ2ZXMiIGlz IG5vdCB0aGUgc2FtZSBhcyAiY29sbGVjdCBpbmZvcm1hdGlvbiBvZmYiLiBDYW4gaXQgYmUgIi4u LiBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uIG9mZiBl eGlzdGluZyB0cmFmZmljIC4uLiI/IEkgdGhpbmsgdGhhdCBhIE1lYXN1cmVtZW50IEFnZW50IG1h eSBjb29yZGluYXRlIGl0cyBhY3Rpb25zIGluIHBlcmZvcm1pbmcgUGFzc2l2ZSBNZWFzdXJlbWVu dCBUYXNrIHdpdGggb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRzL1BlZXJzLiBNb3JlIG9uIGl0IGJl bG93Lg0KDQpbcGhpbF0gSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IGRpZmZlcmVuY2Ug eW91J3JlIGdldHRpbmcgYXQgLSB3aGF0IG1lYW5pbmcgZG8geW91IHdhbnQgdG8gY29udmV5IHdp dGggImNvbGxlY3QgaW5mb3JtYXRpb24iIHRoYXQgZGlmZmVycyBmcm9tICJvYnNlcnZlcyI/DQoN Cg0KDQpBY3RpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNo IGEgTWVhc3VyZW1lbnQgQWdlbnQgc2VuZHMgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgdG8s IG9yIHJlY2VpdmVzIGl0IGZyb20sIG9uZSBvciBtb3JlIG90aGVyIE1lYXN1cmVtZW50IEFnZW50 cyBvciBNZWFzdXJlbWVudCBQZWVycywgYW5kIHBlcmhhcHMgY29vcmRpbmF0ZXMgd2l0aCB0aGVt IHVzaW5nIHByb3RvY29scyBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZQ0KDQpH SU0+PiBJcyAiQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMiIHRoZSBzYW1lIGFzICJUZXN0IFRy YWZmaWMiPyBBbmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1lbnQgRG9tYWluIG9i amVjdCBkZWZpbmVkIGFzOg0KDQpUaGUgY29tbXVuaXR5IG9mIE1lYXN1cmVtZW50IEFnZW50cyBh bmQgTWVhc3VyZW1lbnQgUGVlcnMgdGhhdCBjb29wZXJhdGUgaW4gcGVyZm9ybWluZyBhIE1lYXN1 cmVtZW50IFRhc2ssIHdoZXRoZXIgQWN0aXZlIG9yIFBhc3NpdmUsIHByZXNlbnQgYSBNZWFzdXJl bWVudCBEb21haW4uIENvb3JkaW5hdGlvbiBwcm90b2NvbChzKSB1c2VkIHdpdGhpbiBNZWFzdXJl bWVudCBEb21haW4gYXJlIG91dHNpZGUgb2YgdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlLg0K VGhlbiBpbiBkZWZpbml0aW9ucyBvZiBBY3RpdmUvUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIGlu IHRoZSBMTUFQIEZyYW1ld29yayB3ZSBjYW4gdXNlIHRoZSBNZWFzdXJlbWVudCBEb21haW4gbGlr ZToNClBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNo IGEgTWVhc3VyZW1lbnQgQWdlbnQgY29sbGVjdHMgaW5mb3JtYXRpb24gb2ZmIGV4aXN0aW5nIHRy YWZmaWMgd2l0aGluIGl0cyBNZWFzdXJlbWVudCBEb21haW4uDQoNCltwaGlsXSB5ZXMsIEFjdGl2 ZSBNZWFzdXJlbWVudCBUcmFmZmljIGlzIHdoYXQgeW91IGNvdWxkIGNhbGwgdGVzdCB0cmFmZmlj IFsiQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWM6IHRoZSBwYWNrZXQocykgZ2VuZXJhdGVkIGlu IG9yZGVyIHRvIGV4ZWN1dGUgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suIl0NCg0KW3BoaWxd IHJlIG1lYXN1cmVtZW50IGRvbWFpbiAtIGkgY2FuIHNlZSB0aGlzIG1heSBiZSBhIHVzZWZ1bCBj b25jZXB0LCBidXQgaSBkb24ndCB0aGluayB3ZSd2ZSBuZWVkZWQgdGhpcyB0ZXJtIHlldCBpbiBs bWFwLiBnaXZlbiBob3cgdHJpY2t5IGFncmVlaW5nIHRlcm1pbm9sb2d5IGlzLCBjYW4gd2UgZGVs YXkgZGVmaW5pbmcgdGhpcyB0ZXJtIHVudGlsIHdlJ3JlIHN1cmUgd2UgbmVlZCBpdC4NCg0KdGhh bmtzDQpwaGlsDQoNCg== --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756DA4Dexmb1corpadtran_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDIN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFy IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWln aHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi5IZWFkaW5nMkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMiBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIjsN Cglmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojNEY4MUJEOw0KCWZvbnQt d2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgSSByZWFkIHRoaXMgZW1haWwgdGhyZWFkIHdoaWNo IGlzIHNpbWlsYXIgdG8gZWFybGllciBvbmVzIGRpc2N1c3NpbmcgYWN0aXZlIHZzLiBwYXNzaXZl LCBJIGtlZXAgdGhpbmtpbmcgYWJvdXQgdGhlIG9ubHkgcGxhY2UgdGhlIGRpc3RpbmN0aW9uIGlz IGJlaW5nIHVzZWQNCiBpbiB0aGUgbG1hcCBmcmFtZXdvcmssIHdoaWNoIGlzIGZvciBzdXBwcmVz c2lvbi4gQW5kLCBJIGtlZXAgdGhpbmtpbmcgdGhhdCB3ZSBhcmUgY3JlYXRpbmcgYSBkaXN0aW5j dGlvbiB0aGUgZGV0YWlscyBvZiB3aGljaCB3ZSBjYW5ub3QgYWdyZWUgb24sIGFuZCB0aGF0IGRp ZmZlcmVudCB0ZXN0IHN5c3RlbSBvcGVyYXRvcnMgJm5ic3A7aW50ZW5kIHRvIHVzZSBpbiBkaWZm ZXJlbnQgd2F5cy4gQW5kIHRoaXMgbGVhZHMgbWUgdG8gdGhpbmsgdGhhdCB0aGVyZQ0KIGlzIGEg YmV0dGVyIHdheSB0byBwcm92aWRlIHRoZSBhZ3JlZWQgc3VwcHJlc3Npb24gYmVoYXZpb3Igd2hp bGUgYWxsb3dpbmcgdGVzdCBzeXN0ZW0gb3BlcmF0b3JzIHRvIG1vZGlmeSBpdCBhcyB0aGV5IHdp c2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5EZWZhdWx0IHN1cHByZXNzaW9uIGJlaGF2aW9yLCBhcyBzcGVjaWZpZWQg aW4gZnJhbWV3b3JrLTA1Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxTdXBwcmVzc2lvbiBtZWFucyB0aGF0IHRo ZSBNQSBkb2VzIG5vdCBiZWdpbiBhbnkgbmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiBUaGUgaW1wYWN0IG9uIG90aGVyIE1lYXN1cmVtZW50 IFRhc2tzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm5vdCBkZWZpbmVkIGJ5IExN QVA7IHNpbmNlIHRoZXkgZG8gbm90IGludm9sdmUgdGhlIE1BIGNyZWF0aW5nIGFueTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0aGVyZSBp cyBubyBuZWVkIHRvIHN1cHByZXNzIHRoZW0sIGhvd2V2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+aXQgbWF5IGJlIHNpbXBsZXIgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGRvIHNv LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBhcnJpdmVkIGF0IHRoaXMgcG9pbnQgYmVjYXVzZSBzdGFr ZWhvbGRlcnMgY291bGQgbm90IGFncmVlIG9uIGhvdyB0byB0cmVhdCBQYXNzaXZlIFRhc2tzLiBB cyBhIHJlc3VsdCwgc29tZSBvcGVyYXRvcnMgbWF5IHN1cHByZXNzIFBhc3NpdmUgVGFza3MgYnkN CiBkZWZhdWx0IGFuZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVlLCB3aXRoIHZhcmlhdGlv bnMgYmV0d2VlbiB0aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNpbmNlIHdlIGFyZSBzdGls bCBkZWJhdGluZyB3aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4gQWN0aXZlIGFuZCBQYXNz aXZlLCB0aGUgbWF0dGVyIGlzIG5vdCBzZXR0bGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBiZXR0 ZXIgd2F5LiBTaW1wbHkgYWRkIGEgZmllbGQg4oCTIGEgQm9vbGVhbiB0cnVlL2ZhbHNlIGZsYWcg aXMgYWxsIHRoYXQgaXMgcmVxdWlyZWQg4oCTIHRvIHRoZSBNZWFzdXJlbWVudCBUYXNrIENvbmZp Z3VyYXRpb24gaW5kaWNhdGluZyB3aGV0aGVyIHRoYXQNCiBUYXNrIGlzIHRvIGJlIHN1cHByZXNz ZWQgYnkgZGVmYXVsdC4gSXQgc2hvcnRjdXRzIHRoZSBBY3RpdmUgUGFzc2l2ZSBhcmd1bWVudHMg KGF0IGxlYXN0LCBpbiBsbWFwKSBhbmQgZ2l2ZXMgb3BlcmF0b3JzIGNvbXBsZXRlIGZyZWVkb20g b3ZlciBkZWZhdWx0IHN1cHByZXNzaW9uIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGRlc2NyaXB0 aW9uIG9mIGEgTWVhc3VyZW1lbnQgTWV0aG9kIGluIGEgcmVnaXN0cnkgY291bGQgY29udGFpbiBh IHJlY29tbWVuZGVkIHZhbHVlIGZvciB0aGUgZmxhZy4gSG93ZXZlciwgb3BlcmF0b3JzIHdvdWxk IGJlIGZyZWUgdG8gdXNlIHRoYXQgdmFsdWUgb3INCiBvdmVycmlkZSBpdCBpbiB0aGVpciBkZXBs b3ltZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2VuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWcgTWlyc2t5PGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAxNCAxMDo0MCBBTTxicj4NCjxiPlRvOjwvYj4g cGhpbGlwLmVhcmRsZXlAYnQuY29tPGJyPg0KPGI+Q2M6PC9iPiBsbWFwQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gRm9sbG93LXVwIG9uIHJlY2VudCBkaXNjdXNzaW9u IGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIFBoaWws PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj50aGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlIHRvIG15IGNv bW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aWYgSSBjb21wYXJlIGNvbW1vbiBpbnRlcnByZXRhdGlvbnMg b2YgJnF1b3Q7b2JzZXJ2ZSZxdW90OyBhbmQgJnF1b3Q7Y29sbGVjdCZxdW90Ozo8bzpwPjwvbzpw PjwvcD4NCjxkaXYgaWQ9ImhlYWR3b3JkIj4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0Om5vcm1hbCI+b2LCt3NlcnZlPGVtPiB2ZXJiPC9lbT4g XMmZYi3LiHrJmXJ2XDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9oMj4NCjxkaXY+DQo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+OiB0byB3YXRjaCBhbmQgc29tZXRpbWVzIGFsc28gbGlzdGVuIHRv IChzb21lb25lIG9yIHNvbWV0aGluZykgY2FyZWZ1bGx5PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+OiB0byBzZWUgYW5kIG5vdGljZSAoc29tZW9uZSBvciBzb21l dGhpbmcpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQo6IHRvIG1ha2UgYSBjb21tZW50IGFib3V0IHNvbWV0aGluZyB5b3Ugbm90aWNlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQp2 cy48bzpwPjwvbzpwPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0Om5vcm1hbCI+Y29swrdsZWN0PGVtPiB2ZXJiPC9lbT4gXGvJmS3LiGxl a3RcPC9zcGFuPg0KPG86cD48L286cD48L2gyPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj46IHRvIGdldCAodGhpbmdzKSBmcm9tIGRpZmZlcmVudCBwbGFjZXMgYW5kIGJyaW5n IHRoZW0gdG9nZXRoZXI8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij46IHRvIGdldCAob25lIG9yIG1vcmUgdGhpbmdzKSBmcm9tIGEgcGxhY2U8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjogdG8gZ2V0IChz aW1pbGFyIHRoaW5ncykgYW5kIGJyaW5nIHRoZW0gdG9nZXRoZXIgYXMgYSBob2JieTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPnRoZSBsYXR0ZXIgc2VlbXMgYXMgbW9yZSBzdWl0YWJsZSBp biBjaGFyYWN0ZXJpemF0aW9uIG9mIHJvbGUgb2YgTUEocykgaW4gZXhlY3V0aW5nIFBhc3NpdmUg TWVhc3VyZW1lbnQgbWV0aG9kcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NClJFOiBNZWFzdXJlbWVudCBE b21haW4uIEdpdmVuIGVhcmxpZXIgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbiB0byB0YWtlIGhv bGlzdGljIGFwcHJvYWNoIHRvIE1BL01QIHJvbGUsIEkgYmVsaWV2ZSB3ZSBhcmUgYXQgdGhlIHBv aW50IHdoZXJlIGRpc2N1c3Npb24gb2YgTWVhc3VyZW1lbnQgRG9tYWluJ3MgZGVmaW5pdGlvbiBh bmQgdXNlIGlzIHRpbWVseSBhbmQgYXBwcm9wcmlhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5PbiBXZWQsIEp1biA0LCAyMDE0IGF0IDg6MzQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86 cGhpbGlwLmVhcmRsZXlAYnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbGlwLmVhcmRsZXlAYnQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlByb3Bvc2FsOi08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JbiB0aGUgSW50cm8sIGFkZCB0byB0aGUg cGFyYWdyYXBoIGFib3V0IEFjdGl2ZSAmYW1wOyBQYXNzaXZlIFRhc2tzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZXJlIG1heSBhbHNvIGJlIE1lYXN1 cmVtZW50IFRhc2tzIHRoYXQgYXJlIGludGVybWVkaWF0ZSBiZXR3ZWVuIFBhc3NpdmUgYW5kIEFj dGl2ZSBvbmVzOyBjb25zaWRlcmF0aW9uIGlzIG91dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3Jr IHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkluIHRl cm1pbm9sb2d5LCB0d2VhayB0aGUgZGVmaW5pdGlvbnM6LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFz dXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgb2JzZXJ2ZXMgZXhpc3Rp bmcgdHJhZmZpYyBidXQgZG9lcyBub3QgaW5qZWN0IEFjdGl2ZSBNZWFzdXJlbWVudA0KIFRyYWZm aWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R0lNJmd0 OyZndDsgSSB0aGluayB0aGF0ICZxdW90O29ic2VydmVzJnF1b3Q7IGlzIG5vdCB0aGUgc2FtZSBh cyAmcXVvdDtjb2xsZWN0IGluZm9ybWF0aW9uIG9mZiZxdW90Oy4gQ2FuIGl0IGJlICZxdW90Oy4u LiBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uDQogb2Zm IGV4aXN0aW5nIHRyYWZmaWMgLi4uJnF1b3Q7PyBJIHRoaW5rIHRoYXQgYSBNZWFzdXJlbWVudCBB Z2VudCBtYXkgY29vcmRpbmF0ZSBpdHMgYWN0aW9ucyBpbiBwZXJmb3JtaW5nIFBhc3NpdmUgTWVh c3VyZW1lbnQgVGFzayB3aXRoIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4gTW9yZSBv biBpdCBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPltwaGlsXSBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgZGlm ZmVyZW5jZSB5b3UncmUgZ2V0dGluZyBhdCAtIHdoYXQgbWVhbmluZyBkbyB5b3Ugd2FudCB0byBj b252ZXkgd2l0aCAmcXVvdDtjb2xsZWN0IGluZm9ybWF0aW9uJnF1b3Q7DQogdGhhdCBkaWZmZXJz IGZyb20gJnF1b3Q7b2JzZXJ2ZXMmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFjdGl2ZSBNZWFzdXJlbWVudCBU YXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBzZW5k cyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0bywgb3IgcmVjZWl2ZXMgaXQgZnJvbSwgb25l IG9yIG1vcmUNCiBvdGhlciBNZWFzdXJlbWVudCBBZ2VudHMgb3IgTWVhc3VyZW1lbnQgUGVlcnMs IGFuZCBwZXJoYXBzIGNvb3JkaW5hdGVzIHdpdGggdGhlbSB1c2luZyBwcm90b2NvbHMgb3V0c2lk ZSB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R0lNJmd0OyZndDsgSXMgJnF1b3Q7 QWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMmcXVvdDsgdGhlIHNhbWUgYXMgJnF1b3Q7VGVzdCBU cmFmZmljJnF1b3Q7PyBBbmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1lbnQgRG9t YWluIG9iamVjdCBkZWZpbmVkIGFzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgY29tbXVuaXR5IG9mIE1lYXN1cmVtZW50IEFnZW50cyBh bmQgTWVhc3VyZW1lbnQgUGVlcnMgdGhhdCBjb29wZXJhdGUgaW4gcGVyZm9ybWluZyBhIE1lYXN1 cmVtZW50IFRhc2ssIHdoZXRoZXIgQWN0aXZlIG9yIFBhc3NpdmUsIHByZXNlbnQNCiBhIE1lYXN1 cmVtZW50IERvbWFpbi4gQ29vcmRpbmF0aW9uIHByb3RvY29sKHMpIHVzZWQgd2l0aGluIE1lYXN1 cmVtZW50IERvbWFpbiBhcmUgb3V0c2lkZSBvZiB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZW4gaW4gZGVmaW5pdGlvbnMgb2Yg QWN0aXZlL1Bhc3NpdmUgTWVhc3VyZW1lbnQgVGFzayBpbiB0aGUgTE1BUCBGcmFtZXdvcmsgd2Ug Y2FuIHVzZSB0aGUgTWVhc3VyZW1lbnQgRG9tYWluIGxpa2U6PGJyPg0KUGFzc2l2ZSBNZWFzdXJl bWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2Vu dCBjb2xsZWN0cyBpbmZvcm1hdGlvbiBvZmYgZXhpc3RpbmcgdHJhZmZpYyB3aXRoaW4gaXRzIE1l YXN1cmVtZW50IERvbWFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5bcGhpbF0geWVzLCBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyBpcyB3aGF0 IHlvdSBjb3VsZCBjYWxsIHRlc3QgdHJhZmZpYyBbJnF1b3Q7QWN0aXZlIE1lYXN1cmVtZW50IFRy YWZmaWM6IHRoZSBwYWNrZXQocykgZ2VuZXJhdGVkIGluIG9yZGVyDQogdG8mbmJzcDtleGVjdXRl IGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiZxdW90O108bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5bcGhpbF0gcmUgbWVhc3VyZW1lbnQgZG9tYWluIC0gaSBjYW4gc2VlIHRo aXMgbWF5IGJlIGEgdXNlZnVsIGNvbmNlcHQsIGJ1dCBpIGRvbid0IHRoaW5rIHdlJ3ZlIG5lZWRl ZCB0aGlzIHRlcm0geWV0IGluIGxtYXAuIGdpdmVuIGhvdw0KIHRyaWNreSBhZ3JlZWluZyB0ZXJt aW5vbG9neSBpcywgY2FuIHdlIGRlbGF5IGRlZmluaW5nIHRoaXMgdGVybSB1bnRpbCB3ZSdyZSBz dXJlIHdlIG5lZWQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRoYW5rczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756DA4Dexmb1corpadtran_-- From nobody Thu Jun 5 00:03:55 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 135651A038D for ; Thu, 5 Jun 2014 00:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uulCAWiEz61p for ; Thu, 5 Jun 2014 00:03:50 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9B1A0352 for ; Thu, 5 Jun 2014 00:03:49 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 0606D1A0314; Thu, 5 Jun 2014 09:03:11 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_524F92B4-7138-4FA0-B417-A540E8C3C570"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Thu, 5 Jun 2014 09:03:11 +0200 Message-Id: References: To: KEN KO X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ftT1AzY1RvEloELElGq-IGoojjo Cc: Greg Mirsky , "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:03:53 -0000 --Apple-Mail=_524F92B4-7138-4FA0-B417-A540E8C3C570 Content-Type: multipart/alternative; boundary="Apple-Mail=_98BB3923-E9B8-404E-AC12-5D91A97F3222" --Apple-Mail=_98BB3923-E9B8-404E-AC12-5D91A97F3222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Ken, all, No hats, comments inline... On 05 Jun 2014, at 01:03, KEN KO wrote: > As I read this email thread which is similar to earlier ones = discussing active vs. passive, I keep thinking about the only place the = distinction is being used in the lmap framework, which is for = suppression. And, I keep thinking that we are creating a distinction the = details of which we cannot agree on, and that different test system = operators intend to use in different ways. And this leads me to think = that there is a better way to provide the agreed suppression behavior = while allowing test system operators to modify it as they wish. > =20 > Default suppression behavior, as specified in framework-05: > =20 > =E2=80=9CSuppression means that the MA does not begin any new > Active Measurement Task. The impact on other Measurement Tasks is > not defined by LMAP; since they do not involve the MA creating any > Active Measurement Traffic there is no need to suppress them, however > it may be simpler for an implementation to do so.=E2=80=9D > =20 > We have arrived at this point because stakeholders could not agree on = how to treat Passive Tasks. As a result, some operators may suppress = Passive Tasks by default and others may let them continue, with = variations between those two extremes. And yet, since we are still = debating where to draw the line between Active and Passive, the matter = is not settled. > =20 > There is a better way. Simply add a field =E2=80=93 a Boolean = true/false flag is all that is required =E2=80=93 to the Measurement = Task Configuration indicating whether that Task is to be suppressed by = default. It shortcuts the Active Passive arguments (at least, in lmap) = and gives operators complete freedom over default suppression behavior. > =20 > The description of a Measurement Method in a registry could contain a = recommended value for the flag. However, operators would be free to use = that value or override it in their deployments. > =20 > Comments? This does seem like a good way _not_ to have this discussion here. I = tend to agree -- the closer that the LMAP framework can get to treating = all Measurement Tasks as black boxes, the properties of which are = task-specific, and only those properties which have an effect on control = flows are exposed to LMAP. Having a "suppression default" property is IMO a _much_ better way to = separate mechanism and policy than trying to infer or impose these = defaults based upon a definition of a class of measurement tasks. I also wanted to make a terminology point on Greg Mirsky's comment, = below: > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Wednesday, June 04, 2014 10:40 AM > To: philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt > =20 > Hi Phil, > thank you for your prompt response to my comments. > if I compare common interpretations of "observe" and "collect": > ob=C2=B7serve verb \=C9=99b-=CB=88z=C9=99rv\ >=20 > : to watch and sometimes also listen to (someone or something) = carefully >=20 > : to see and notice (someone or something) >=20 > : to make a comment about something you notice > vs. > col=C2=B7lect verb \k=C9=99-=CB=88lekt\ >=20 > : to get (things) from different places and bring them together >=20 > : to get (one or more things) from a place >=20 > : to get (similar things) and bring them together as a hobby > the latter seems as more suitable in characterization of role of MA(s) = in executing Passive Measurement methods. I tend to disagree -- not with your analysis of common definitions of = the terms "observe" and "collect", but with the terms as they have been = used in passive measurement architectures in the IETF. Here I refer to = RFC 7011, section 2: Observation Point An Observation Point is a location in the network where packets can be observed. Examples include a line to which a probe is attached; a shared medium, such as an Ethernet-based LAN; a single port of a router; or a set of interfaces (physical or logical) of a router. Collecting Process A Collecting Process receives IPFIX Messages from one or more Exporting Processes. The Collecting Process might process or store Flow Records received within these Messages, but such actions are out of scope for this document. In this case, an MA hosts one or more Observation Points, and therefore = observes the traffic. _Collection_ is the act of receiving reports from = an MA at... ah, at a Collector (-framework-05 section 3): Collector: A function that receives a Report from a Measurement Agent. Cheers, Brian --Apple-Mail=_98BB3923-E9B8-404E-AC12-5D91A97F3222 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 hi = Ken, all,

No hats, comments = inline...

On 05 Jun 2014, at 01:03, = KEN KO <KEN.KO@adtran.com> = wrote:

As I read this email thread which is similar to = earlier ones discussing active vs. passive, I keep thinking about the = only place the distinction is being used in the lmap framework, which is = for suppression. And, I keep thinking that we are creating a distinction = the details of which we cannot agree on, and that different test system = operators  intend to use in different ways. And this leads me to = think that there is a better way to provide the agreed suppression = behavior while allowing test system operators to modify it as they = wish.
 
Default suppression behavior, as specified in = framework-05:
 
=E2=80=9CSuppression means that the MA does not begin = any new
Active Measurement Task. The impact on other = Measurement Tasks is
not defined by LMAP; since they do = not involve the MA creating any
Active Measurement = Traffic there is no need to suppress them, = however
it may be simpler for an implementation to do = so.=E2=80=9D
 
We have arrived at this point because stakeholders = could not agree on how to treat Passive Tasks. As a result, some = operators may suppress Passive Tasks by default and others may let them = continue, with variations between those two extremes. And yet, since we = are still debating where to draw the line between Active and Passive, = the matter is not settled.
 
There is a better way. = Simply add a field =E2=80=93 a Boolean true/false flag is all that is = required =E2=80=93 to the Measurement Task Configuration indicating = whether that Task is to be suppressed by default. It shortcuts the = Active Passive arguments (at least, in lmap) and gives operators = complete freedom over default suppression = behavior.
 
The description of a Measurement Method in a registry = could contain a recommended value for the flag. However, operators would = be free to use that value or override it in their = deployments.
 
Comments?

= This does seem like a good way _not_ to have this discussion here. I = tend to agree -- the closer that the LMAP framework can get to treating = all Measurement Tasks as black boxes, the properties of which are = task-specific, and only those properties which have an effect on control = flows are exposed to LMAP.

Having a = "suppression default" property is IMO a _much_ better way to separate = mechanism and policy than trying to infer or impose these defaults based = upon a definition of a class of measurement = tasks.

I also wanted to make a terminology = point on Greg Mirsky's comment, below:

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg = Mirsky
Sent: Wednesday, June 04, 2014 = 10:40 AM
To: philip.eardley@bt.com
Cc:<= /b> lmap@ietf.org
Subject:<= /b> Re: [lmap] = Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt
 
Hi Phil,
thank you for your prompt response to my = comments.
if I = compare common interpretations of "observe" and = "collect":

ob=C2=B7serve verb \=C9=99b-=CB=88z=C9=99rv\

: to = watch and sometimes also listen to (someone or something) = carefully

: to see = and notice (someone or something)

: to make a comment about something you = notice
vs.

col=C2=B7lect verb \k=C9=99-=CB=88lekt\

: to get = (things) from different places and bring them together

: to get (one or more things) = from a place

: to get = (similar things) and bring them together as a = hobby
the latter seems as more suitable in characterization of role of = MA(s) in executing Passive Measurement = methods.

I tend to disagree -- not with your analysis of common = definitions of the terms "observe" and "collect", but with the terms as = they have been used in passive measurement architectures in the IETF. = Here I refer to RFC 7011, section 2:

   Observation Point

      An Observation Point is a location in the network where packets
      can be observed.  Examples include a line to which a probe is
      attached; a shared medium, such as an Ethernet-based LAN; a single
      port of a router; or a set of interfaces (physical or logical) of
      a router.

   Collecting Process

      A Collecting Process receives IPFIX Messages from one or more
      Exporting Processes.  The Collecting Process might process or
      store Flow Records received within these Messages, but such
      actions are out of scope for this =
document.

In this case, an MA hosts one = or more Observation Points, and therefore observes the traffic. = _Collection_ is the act of receiving reports from an MA at... ah, at a = Collector (-framework-05 section 3):

   Collector: A function that receives a Report from a =
Measurement
   =
Agent.

Cheers,

Bri= an
= --Apple-Mail=_98BB3923-E9B8-404E-AC12-5D91A97F3222-- --Apple-Mail=_524F92B4-7138-4FA0-B417-A540E8C3C570 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 iQEcBAEBCgAGBQJTkBYvAAoJENt3nsOmbNJc8JYH/1q6WghOcLkGRowbSm/qTnM3 fSS/we0QPnpMK/gn9qdLTENHAZvLyNe8zSEbm4FUvSDxZGEEElwzppOe4cwHiWgd ZFnG5kil1uE7ffen5NHDFcTnd8orcjPVrz0cGr57+hYmu6+K5KzE5LMNWVxDxbUS 9HRM8CfEPyLlBqUxOfmpF9raldq/iVLzw+biQdyoW/WBEEMRlNwI4gj4YF8s66sl xqDII/JNHkW5rgX8fHHrMLN4ymdcUr/BJhS1YnJ6XAJBkQLzwZ+PCzJrhwMzfwYG AgiTwTdeMYRS3x5q600R9EFCbUYUZug+wB1QBe3faTrWgA0Annrl5mmNSYUYTvo= =KnOn -----END PGP SIGNATURE----- --Apple-Mail=_524F92B4-7138-4FA0-B417-A540E8C3C570-- From nobody Thu Jun 5 02:14:30 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4371A03BE for ; Thu, 5 Jun 2014 02:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 bLGRDH8m2NWL for ; Thu, 5 Jun 2014 02:14:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462BB1A0365 for ; Thu, 5 Jun 2014 02:14:24 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 5 Jun 2014 10:10:19 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 5 Jun 2014 10:13:22 +0100 From: To: , Date: Thu, 5 Jun 2014 10:13:21 +0100 Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojf/1VECZMV+0q/TqGdomu4/5tha54AgAASfACAAAsT0IAAtAtm Message-ID: References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_VhfDe7GAPhJ6ZypEN-79yDDWlw Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:14:29 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419EMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aSB0aGluayB0aGlzIGlzIGEgdmVyeSBnb29kIHN1Z2dlc3Rpb24uIGkgYWdyZWUgdGhpcyBpcyB0 aGUgcmlnaHQgd2F5IG9mIHNlcGFyYXRpbmcgcG9saWN5IGFuZCBwcm90b2NvbA0KDQphcyBhIHNp ZGUgYmVuZWZpdCwgd2UgY2FuIHRoZW4gZHJvcCB0aGUgYWN0aXZlIHZzIHBhc3NpdmUgZGlzdGlu Y3Rpb24gKGFuZCB0ZXJtaW5vbG9neSkgKGFuZCBkbyBzb21lIHNsaWdodCByZXBocmFzaW5nIGlu IHRoZSBwcml2YWN5IHNlY3Rpb24sIHdoaWNoIGlzIHRoZSBtYWluIHBsYWNlIHRoYXQgdXNlcyB0 aGUgdGVybXMpDQoNCnRoYW5rcw0KcGhpbA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogS0VOIEtPIFtLRU4uS09AYWR0cmFuLmNvbV0NClNlbnQ6IDA1IEp1bmUgMjAx NCAwMDowMw0KVG86IEdyZWcgTWlyc2t5OyBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFINCkNjOiBs bWFwQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlz Y3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dA0KDQpBcyBJIHJl YWQgdGhpcyBlbWFpbCB0aHJlYWQgd2hpY2ggaXMgc2ltaWxhciB0byBlYXJsaWVyIG9uZXMgZGlz Y3Vzc2luZyBhY3RpdmUgdnMuIHBhc3NpdmUsIEkga2VlcCB0aGlua2luZyBhYm91dCB0aGUgb25s eSBwbGFjZSB0aGUgZGlzdGluY3Rpb24gaXMgYmVpbmcgdXNlZCBpbiB0aGUgbG1hcCBmcmFtZXdv cmssIHdoaWNoIGlzIGZvciBzdXBwcmVzc2lvbi4gQW5kLCBJIGtlZXAgdGhpbmtpbmcgdGhhdCB3 ZSBhcmUgY3JlYXRpbmcgYSBkaXN0aW5jdGlvbiB0aGUgZGV0YWlscyBvZiB3aGljaCB3ZSBjYW5u b3QgYWdyZWUgb24sIGFuZCB0aGF0IGRpZmZlcmVudCB0ZXN0IHN5c3RlbSBvcGVyYXRvcnMgIGlu dGVuZCB0byB1c2UgaW4gZGlmZmVyZW50IHdheXMuIEFuZCB0aGlzIGxlYWRzIG1lIHRvIHRoaW5r IHRoYXQgdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRvIHByb3ZpZGUgdGhlIGFncmVlZCBzdXBwcmVz c2lvbiBiZWhhdmlvciB3aGlsZSBhbGxvd2luZyB0ZXN0IHN5c3RlbSBvcGVyYXRvcnMgdG8gbW9k aWZ5IGl0IGFzIHRoZXkgd2lzaC4NCg0KRGVmYXVsdCBzdXBwcmVzc2lvbiBiZWhhdmlvciwgYXMg c3BlY2lmaWVkIGluIGZyYW1ld29yay0wNToNCg0K4oCcU3VwcHJlc3Npb24gbWVhbnMgdGhhdCB0 aGUgTUEgZG9lcyBub3QgYmVnaW4gYW55IG5ldw0KQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suIFRo ZSBpbXBhY3Qgb24gb3RoZXIgTWVhc3VyZW1lbnQgVGFza3MgaXMNCm5vdCBkZWZpbmVkIGJ5IExN QVA7IHNpbmNlIHRoZXkgZG8gbm90IGludm9sdmUgdGhlIE1BIGNyZWF0aW5nIGFueQ0KQWN0aXZl IE1lYXN1cmVtZW50IFRyYWZmaWMgdGhlcmUgaXMgbm8gbmVlZCB0byBzdXBwcmVzcyB0aGVtLCBo b3dldmVyDQppdCBtYXkgYmUgc2ltcGxlciBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gc28u 4oCdDQoNCldlIGhhdmUgYXJyaXZlZCBhdCB0aGlzIHBvaW50IGJlY2F1c2Ugc3Rha2Vob2xkZXJz IGNvdWxkIG5vdCBhZ3JlZSBvbiBob3cgdG8gdHJlYXQgUGFzc2l2ZSBUYXNrcy4gQXMgYSByZXN1 bHQsIHNvbWUgb3BlcmF0b3JzIG1heSBzdXBwcmVzcyBQYXNzaXZlIFRhc2tzIGJ5IGRlZmF1bHQg YW5kIG90aGVycyBtYXkgbGV0IHRoZW0gY29udGludWUsIHdpdGggdmFyaWF0aW9ucyBiZXR3ZWVu IHRob3NlIHR3byBleHRyZW1lcy4gQW5kIHlldCwgc2luY2Ugd2UgYXJlIHN0aWxsIGRlYmF0aW5n IHdoZXJlIHRvIGRyYXcgdGhlIGxpbmUgYmV0d2VlbiBBY3RpdmUgYW5kIFBhc3NpdmUsIHRoZSBt YXR0ZXIgaXMgbm90IHNldHRsZWQuDQoNClRoZXJlIGlzIGEgYmV0dGVyIHdheS4gU2ltcGx5IGFk ZCBhIGZpZWxkIOKAkyBhIEJvb2xlYW4gdHJ1ZS9mYWxzZSBmbGFnIGlzIGFsbCB0aGF0IGlzIHJl cXVpcmVkIOKAkyB0byB0aGUgTWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIGluZGljYXRp bmcgd2hldGhlciB0aGF0IFRhc2sgaXMgdG8gYmUgc3VwcHJlc3NlZCBieSBkZWZhdWx0LiBJdCBz aG9ydGN1dHMgdGhlIEFjdGl2ZSBQYXNzaXZlIGFyZ3VtZW50cyAoYXQgbGVhc3QsIGluIGxtYXAp IGFuZCBnaXZlcyBvcGVyYXRvcnMgY29tcGxldGUgZnJlZWRvbSBvdmVyIGRlZmF1bHQgc3VwcHJl c3Npb24gYmVoYXZpb3IuDQoNClRoZSBkZXNjcmlwdGlvbiBvZiBhIE1lYXN1cmVtZW50IE1ldGhv ZCBpbiBhIHJlZ2lzdHJ5IGNvdWxkIGNvbnRhaW4gYSByZWNvbW1lbmRlZCB2YWx1ZSBmb3IgdGhl IGZsYWcuIEhvd2V2ZXIsIG9wZXJhdG9ycyB3b3VsZCBiZSBmcmVlIHRvIHVzZSB0aGF0IHZhbHVl IG9yIG92ZXJyaWRlIGl0IGluIHRoZWlyIGRlcGxveW1lbnRzLg0KDQpDb21tZW50cz8NCg0KS2Vu DQoNCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEdyZWcgTWlyc2t5DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgMTA6NDAgQU0N ClRvOiBwaGlsaXAuZWFyZGxleUBidC5jb20NCkNjOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRm LWxtYXAtZnJhbWV3b3JrLTA1LnR4dA0KDQpIaSBQaGlsLA0KdGhhbmsgeW91IGZvciB5b3VyIHBy b21wdCByZXNwb25zZSB0byBteSBjb21tZW50cy4NCmlmIEkgY29tcGFyZSBjb21tb24gaW50ZXJw cmV0YXRpb25zIG9mICJvYnNlcnZlIiBhbmQgImNvbGxlY3QiOg0Kb2LCt3NlcnZlIHZlcmIgXMmZ Yi3LiHrJmXJ2XA0KDQo6IHRvIHdhdGNoIGFuZCBzb21ldGltZXMgYWxzbyBsaXN0ZW4gdG8gKHNv bWVvbmUgb3Igc29tZXRoaW5nKSBjYXJlZnVsbHkNCg0KOiB0byBzZWUgYW5kIG5vdGljZSAoc29t ZW9uZSBvciBzb21ldGhpbmcpDQo6IHRvIG1ha2UgYSBjb21tZW50IGFib3V0IHNvbWV0aGluZyB5 b3Ugbm90aWNlDQp2cy4NCmNvbMK3bGVjdCB2ZXJiIFxryZkty4hsZWt0XA0KDQo6IHRvIGdldCAo dGhpbmdzKSBmcm9tIGRpZmZlcmVudCBwbGFjZXMgYW5kIGJyaW5nIHRoZW0gdG9nZXRoZXINCg0K OiB0byBnZXQgKG9uZSBvciBtb3JlIHRoaW5ncykgZnJvbSBhIHBsYWNlDQo6IHRvIGdldCAoc2lt aWxhciB0aGluZ3MpIGFuZCBicmluZyB0aGVtIHRvZ2V0aGVyIGFzIGEgaG9iYnkNCnRoZSBsYXR0 ZXIgc2VlbXMgYXMgbW9yZSBzdWl0YWJsZSBpbiBjaGFyYWN0ZXJpemF0aW9uIG9mIHJvbGUgb2Yg TUEocykgaW4gZXhlY3V0aW5nIFBhc3NpdmUgTWVhc3VyZW1lbnQgbWV0aG9kcy4NClJFOiBNZWFz dXJlbWVudCBEb21haW4uIEdpdmVuIGVhcmxpZXIgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbiB0 byB0YWtlIGhvbGlzdGljIGFwcHJvYWNoIHRvIE1BL01QIHJvbGUsIEkgYmVsaWV2ZSB3ZSBhcmUg YXQgdGhlIHBvaW50IHdoZXJlIGRpc2N1c3Npb24gb2YgTWVhc3VyZW1lbnQgRG9tYWluJ3MgZGVm aW5pdGlvbiBhbmQgdXNlIGlzIHRpbWVseSBhbmQgYXBwcm9wcmlhdGUuDQpSZWdhcmRzLA0KR3Jl Zw0KDQpPbiBXZWQsIEp1biA0LCAyMDE0IGF0IDg6MzQgQU0sIDxwaGlsaXAuZWFyZGxleUBidC5j b208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4+IHdyb3RlOg0KDQoNClByb3Bvc2FsOi0N Cg0KSW4gdGhlIEludHJvLCBhZGQgdG8gdGhlIHBhcmFncmFwaCBhYm91dCBBY3RpdmUgJiBQYXNz aXZlIFRhc2tzOg0KDQpUaGVyZSBtYXkgYWxzbyBiZSBNZWFzdXJlbWVudCBUYXNrcyB0aGF0IGFy ZSBpbnRlcm1lZGlhdGUgYmV0d2VlbiBQYXNzaXZlIGFuZCBBY3RpdmUgb25lczsgY29uc2lkZXJh dGlvbiBpcyBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZS4NCg0KDQoNCkluIHRl cm1pbm9sb2d5LCB0d2VhayB0aGUgZGVmaW5pdGlvbnM6LQ0KDQpQYXNzaXZlIE1lYXN1cmVtZW50 IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9i c2VydmVzIGV4aXN0aW5nIHRyYWZmaWMgYnV0IGRvZXMgbm90IGluamVjdCBBY3RpdmUgTWVhc3Vy ZW1lbnQgVHJhZmZpYy4NCg0KR0lNPj4gSSB0aGluayB0aGF0ICJvYnNlcnZlcyIgaXMgbm90IHRo ZSBzYW1lIGFzICJjb2xsZWN0IGluZm9ybWF0aW9uIG9mZiIuIENhbiBpdCBiZSAiLi4uIGluIHdo aWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgY29sbGVjdHMgaW5mb3JtYXRpb24gb2ZmIGV4aXN0aW5n IHRyYWZmaWMgLi4uIj8gSSB0aGluayB0aGF0IGEgTWVhc3VyZW1lbnQgQWdlbnQgbWF5IGNvb3Jk aW5hdGUgaXRzIGFjdGlvbnMgaW4gcGVyZm9ybWluZyBQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2sg d2l0aCBvdGhlciBNZWFzdXJlbWVudCBBZ2VudHMvUGVlcnMuIE1vcmUgb24gaXQgYmVsb3cuDQoN CltwaGlsXSBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgZGlmZmVyZW5jZSB5b3UncmUg Z2V0dGluZyBhdCAtIHdoYXQgbWVhbmluZyBkbyB5b3Ugd2FudCB0byBjb252ZXkgd2l0aCAiY29s bGVjdCBpbmZvcm1hdGlvbiIgdGhhdCBkaWZmZXJzIGZyb20gIm9ic2VydmVzIj8NCg0KDQoNCkFj dGl2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFz dXJlbWVudCBBZ2VudCBzZW5kcyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0bywgb3IgcmVj ZWl2ZXMgaXQgZnJvbSwgb25lIG9yIG1vcmUgb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRzIG9yIE1l YXN1cmVtZW50IFBlZXJzLCBhbmQgcGVyaGFwcyBjb29yZGluYXRlcyB3aXRoIHRoZW0gdXNpbmcg cHJvdG9jb2xzIG91dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlDQoNCkdJTT4+IElz ICJBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyIgdGhlIHNhbWUgYXMgIlRlc3QgVHJhZmZpYyI/ IEFuZCBJJ2QgbGlrZSB0byBkaXNjdXNzIG5ldyBNZWFzdXJlbWVudCBEb21haW4gb2JqZWN0IGRl ZmluZWQgYXM6DQoNClRoZSBjb21tdW5pdHkgb2YgTWVhc3VyZW1lbnQgQWdlbnRzIGFuZCBNZWFz dXJlbWVudCBQZWVycyB0aGF0IGNvb3BlcmF0ZSBpbiBwZXJmb3JtaW5nIGEgTWVhc3VyZW1lbnQg VGFzaywgd2hldGhlciBBY3RpdmUgb3IgUGFzc2l2ZSwgcHJlc2VudCBhIE1lYXN1cmVtZW50IERv bWFpbi4gQ29vcmRpbmF0aW9uIHByb3RvY29sKHMpIHVzZWQgd2l0aGluIE1lYXN1cmVtZW50IERv bWFpbiBhcmUgb3V0c2lkZSBvZiB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuDQpUaGVuIGlu IGRlZmluaXRpb25zIG9mIEFjdGl2ZS9QYXNzaXZlIE1lYXN1cmVtZW50IFRhc2sgaW4gdGhlIExN QVAgRnJhbWV3b3JrIHdlIGNhbiB1c2UgdGhlIE1lYXN1cmVtZW50IERvbWFpbiBsaWtlOg0KUGFz c2l2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFz dXJlbWVudCBBZ2VudCBjb2xsZWN0cyBpbmZvcm1hdGlvbiBvZmYgZXhpc3RpbmcgdHJhZmZpYyB3 aXRoaW4gaXRzIE1lYXN1cmVtZW50IERvbWFpbi4NCg0KW3BoaWxdIHllcywgQWN0aXZlIE1lYXN1 cmVtZW50IFRyYWZmaWMgaXMgd2hhdCB5b3UgY291bGQgY2FsbCB0ZXN0IHRyYWZmaWMgWyJBY3Rp dmUgTWVhc3VyZW1lbnQgVHJhZmZpYzogdGhlIHBhY2tldChzKSBnZW5lcmF0ZWQgaW4gb3JkZXIg dG8gZXhlY3V0ZSBhbiBBY3RpdmUgTWVhc3VyZW1lbnQgVGFzay4iXQ0KDQpbcGhpbF0gcmUgbWVh c3VyZW1lbnQgZG9tYWluIC0gaSBjYW4gc2VlIHRoaXMgbWF5IGJlIGEgdXNlZnVsIGNvbmNlcHQs IGJ1dCBpIGRvbid0IHRoaW5rIHdlJ3ZlIG5lZWRlZCB0aGlzIHRlcm0geWV0IGluIGxtYXAuIGdp dmVuIGhvdyB0cmlja3kgYWdyZWVpbmcgdGVybWlub2xvZ3kgaXMsIGNhbiB3ZSBkZWxheSBkZWZp bmluZyB0aGlzIHRlcm0gdW50aWwgd2UncmUgc3VyZSB3ZSBuZWVkIGl0Lg0KDQp0aGFua3MNCnBo aWwNCg0K --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419EMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPHN0eWxlPkBmb250LWZhY2Ugew0K CWZvbnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRh aG9tYTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7bWFyZ2luOiAxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjsgfQ0KUC5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZ OiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBGT05ULVNJWkU6IDEycHQNCn0NCkxJLk1zb05v cm1hbCB7DQoJTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7IEZPTlQtU0laRTogMTJwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJTUFSR0lO OiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IEZP TlQtU0laRTogMTJwdA0KfQ0KSDIgew0KCUZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiOyBNQVJHSU4tTEVGVDogMGluOyBGT05ULVNJWkU6IDE4cHQ7IEZPTlQtV0VJR0hUOiBi b2xkOyBNQVJHSU4tUklHSFQ6IDBpbg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1 cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9s bG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpQ IHsNCglGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgTUFSR0lOLUxFRlQ6 IDBpbjsgRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU4tUklHSFQ6IDBpbg0KfQ0KU1BBTi5IZWFkaW5n MkNoYXIgew0KCUZPTlQtRkFNSUxZOiAiQ2FtYnJpYSIsInNlcmlmIjsgQ09MT1I6ICM0ZjgxYmQ7 IEZPTlQtV0VJR0hUOiBib2xkDQp9DQpTUEFOLkVtYWlsU3R5bGUyMCB7DQoJRk9OVC1GQU1JTFk6 ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkDQp9DQouTXNvQ2hwRGVmYXVs dCB7DQoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiINCn0NCkRJVi5Xb3JkU2Vj dGlvbjEgew0KCQ0KfQ0KPC9zdHlsZT4NCjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0i TVNIVE1MIDkuMDAuODExMi4xNjU0NSI+DQo8c3R5bGUgaWQ9Im93YVRlbXBFZGl0U3R5bGUiPjwv c3R5bGU+PHN0eWxlIHRpdGxlPSJvd2FQYXJhU3R5bGUiPjwhLS1QIHsNCglNQVJHSU4tVE9QOiAw cHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiB2bGluaz0icHVycGxlIiBsaW5rPSJibHVlIiBvY3NpPSJ4Ij4NCjxkaXYgc3R5 bGU9IkZPTlQtRkFNSUxZOiBUYWhvbWE7IERJUkVDVElPTjogbHRyOyBDT0xPUjogIzAwMDAwMDsg Rk9OVC1TSVpFOiB4LXNtYWxsIj4NCjxkaXY+aSB0aGluayB0aGlzIGlzIGEgdmVyeSBnb29kIHN1 Z2dlc3Rpb24uIGkgYWdyZWUgdGhpcyBpcyB0aGUgcmlnaHQgd2F5IG9mIHNlcGFyYXRpbmcgcG9s aWN5IGFuZCBwcm90b2NvbDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJ0YWhvbWEiPjwvZm9udD4m bmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0idGFob21hIj5hcyBhIHNpZGUgYmVuZWZpdCwg PC9mb250Pjxmb250IGZhY2U9InRhaG9tYSI+d2UgY2FuIHRoZW4gZHJvcCB0aGUgYWN0aXZlIHZz IHBhc3NpdmUgZGlzdGluY3Rpb24gKGFuZCB0ZXJtaW5vbG9neSkgKGFuZCBkbyBzb21lIHNsaWdo dCByZXBocmFzaW5nIGluIHRoZSBwcml2YWN5IHNlY3Rpb24sIHdoaWNoIGlzIHRoZSBtYWluIHBs YWNlIHRoYXQgdXNlcyB0aGUgdGVybXMpPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJ0 YWhvbWEiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0idGFob21hIj50aGFu a3M8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9InRhaG9tYSI+cGhpbDwvZm9udD48L2Rp dj4NCjxkaXYgZGlyPSJsdHIiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJU YWhvbWEiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkRJUkVDVElPTjogbHRyIiBp ZD0iZGl2UnBGNjg2MDUiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8Zm9udCBjb2xvcj0iIzAwMDAw MCIgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gS0VOIEtPIFtLRU4uS09AYWR0 cmFuLmNvbV08YnI+DQo8Yj5TZW50OjwvYj4gMDUgSnVuZSAyMDE0IDAwOjAzPGJyPg0KPGI+VG86 PC9iPiBHcmVnIE1pcnNreTsgRWFyZGxleSxQTCxQaGlsaXAsVFVCOCBSPGJyPg0KPGI+Q2M6PC9i PiBsbWFwQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbG1hcF0gRm9sbG93LXVw IG9uIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUu dHh0PGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1T SVpFOiAxMXB0Ij5BcyBJIHJlYWQgdGhpcyBlbWFpbCB0aHJlYWQgd2hpY2ggaXMgc2ltaWxhciB0 byBlYXJsaWVyIG9uZXMgZGlzY3Vzc2luZyBhY3RpdmUgdnMuIHBhc3NpdmUsIEkga2VlcCB0aGlu a2luZyBhYm91dCB0aGUgb25seSBwbGFjZSB0aGUgZGlzdGluY3Rpb24gaXMgYmVpbmcNCiB1c2Vk IGluIHRoZSBsbWFwIGZyYW1ld29yaywgd2hpY2ggaXMgZm9yIHN1cHByZXNzaW9uLiBBbmQsIEkg a2VlcCB0aGlua2luZyB0aGF0IHdlIGFyZSBjcmVhdGluZyBhIGRpc3RpbmN0aW9uIHRoZSBkZXRh aWxzIG9mIHdoaWNoIHdlIGNhbm5vdCBhZ3JlZSBvbiwgYW5kIHRoYXQgZGlmZmVyZW50IHRlc3Qg c3lzdGVtIG9wZXJhdG9ycyAmbmJzcDtpbnRlbmQgdG8gdXNlIGluIGRpZmZlcmVudCB3YXlzLiBB bmQgdGhpcyBsZWFkcyBtZSB0byB0aGluayB0aGF0DQogdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRv IHByb3ZpZGUgdGhlIGFncmVlZCBzdXBwcmVzc2lvbiBiZWhhdmlvciB3aGlsZSBhbGxvd2luZyB0 ZXN0IHN5c3RlbSBvcGVyYXRvcnMgdG8gbW9kaWZ5IGl0IGFzIHRoZXkgd2lzaC48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0 Ij5EZWZhdWx0IHN1cHByZXNzaW9uIGJlaGF2aW9yLCBhcyBzcGVjaWZpZWQgaW4gZnJhbWV3b3Jr LTA1Og0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0la RTogMTFwdCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtU0laRTogMTFwdCI+4oCcU3VwcHJlc3Npb24gbWVhbnMgdGhhdCB0aGUgTUEgZG9lcyBu b3QgYmVnaW4gYW55IG5ldzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdk OyBGT05ULVNJWkU6IDExcHQiPkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiBUaGUgaW1wYWN0IG9u IG90aGVyIE1lYXN1cmVtZW50IFRhc2tzIGlzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+bm90IGRlZmluZWQgYnkgTE1BUDsgc2luY2Ug dGhleSBkbyBub3QgaW52b2x2ZSB0aGUgTUEgY3JlYXRpbmcgYW55PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+QWN0aXZlIE1lYXN1cmVt ZW50IFRyYWZmaWMgdGhlcmUgaXMgbm8gbmVlZCB0byBzdXBwcmVzcyB0aGVtLCBob3dldmVyPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+ aXQgbWF5IGJlIHNpbXBsZXIgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGRvIHNvLuKAnTwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjwv c3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6 IDExcHQiPldlIGhhdmUgYXJyaXZlZCBhdCB0aGlzIHBvaW50IGJlY2F1c2Ugc3Rha2Vob2xkZXJz IGNvdWxkIG5vdCBhZ3JlZSBvbiBob3cgdG8gdHJlYXQgUGFzc2l2ZSBUYXNrcy4gQXMgYSByZXN1 bHQsIHNvbWUgb3BlcmF0b3JzIG1heSBzdXBwcmVzcyBQYXNzaXZlIFRhc2tzDQogYnkgZGVmYXVs dCBhbmQgb3RoZXJzIG1heSBsZXQgdGhlbSBjb250aW51ZSwgd2l0aCB2YXJpYXRpb25zIGJldHdl ZW4gdGhvc2UgdHdvIGV4dHJlbWVzLiBBbmQgeWV0LCBzaW5jZSB3ZSBhcmUgc3RpbGwgZGViYXRp bmcgd2hlcmUgdG8gZHJhdyB0aGUgbGluZSBiZXR3ZWVuIEFjdGl2ZSBhbmQgUGFzc2l2ZSwgdGhl IG1hdHRlciBpcyBub3Qgc2V0dGxlZC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5UaGVyZSBpcyBhIGJldHRlciB3YXku IFNpbXBseSBhZGQgYSBmaWVsZCDigJMgYSBCb29sZWFuIHRydWUvZmFsc2UgZmxhZyBpcyBhbGwg dGhhdCBpcyByZXF1aXJlZCDigJMgdG8gdGhlIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJhdGlv biBpbmRpY2F0aW5nIHdoZXRoZXINCiB0aGF0IFRhc2sgaXMgdG8gYmUgc3VwcHJlc3NlZCBieSBk ZWZhdWx0LiBJdCBzaG9ydGN1dHMgdGhlIEFjdGl2ZSBQYXNzaXZlIGFyZ3VtZW50cyAoYXQgbGVh c3QsIGluIGxtYXApIGFuZCBnaXZlcyBvcGVyYXRvcnMgY29tcGxldGUgZnJlZWRvbSBvdmVyIGRl ZmF1bHQgc3VwcHJlc3Npb24gYmVoYXZpb3IuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+VGhlIGRlc2NyaXB0aW9uIG9m IGEgTWVhc3VyZW1lbnQgTWV0aG9kIGluIGEgcmVnaXN0cnkgY291bGQgY29udGFpbiBhIHJlY29t bWVuZGVkIHZhbHVlIGZvciB0aGUgZmxhZy4gSG93ZXZlciwgb3BlcmF0b3JzIHdvdWxkIGJlIGZy ZWUgdG8gdXNlIHRoYXQgdmFsdWUNCiBvciBvdmVycmlkZSBpdCBpbiB0aGVpciBkZXBsb3ltZW50 cy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAx MXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O VC1TSVpFOiAxMXB0Ij5Db21tZW50cz88L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5LZW48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+ Jm5ic3A7PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZP TlQtU0laRTogMTBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPiBsbWFwIFttYWlsdG86bG1h cC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgMTA6NDAgQU08YnI+DQo8Yj5U bzo8L2I+IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxicj4NCjxiPkNjOjwvYj4gbG1hcEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlz Y3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj5IaSBQaGlsLDwvcD4NCjwvZGl2 Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsg eW91IGZvciB5b3VyIHByb21wdCByZXNwb25zZSB0byBteSBjb21tZW50cy48L3A+DQo8L2Rpdj4N CjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPmlmIEkgY29t cGFyZSBjb21tb24gaW50ZXJwcmV0YXRpb25zIG9mICZxdW90O29ic2VydmUmcXVvdDsgYW5kICZx dW90O2NvbGxlY3QmcXVvdDs6PC9wPg0KPGRpdiBpZD0iaGVhZHdvcmQiPg0KPGgyIHN0eWxlPSJN QVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsIj5vYsK3 c2VydmU8ZW0+IHZlcmI8L2VtPiBcyZliLcuIesmZcnZcPC9zcGFuPg0KPC9oMj4NCjxkaXY+DQo8 cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj46IHRvIHdhdGNoIGFuZCBzb21ldGltZXMgYWxz byBsaXN0ZW4gdG8gKHNvbWVvbmUgb3Igc29tZXRoaW5nKSBjYXJlZnVsbHk8L3A+DQo8cCBzdHls ZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj46IHRvIHNlZSBhbmQgbm90aWNlIChzb21lb25lIG9yIHNv bWV0aGluZyk8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9y bWFsIj46IHRvIG1ha2UgYSBjb21tZW50IGFib3V0IHNvbWV0aGluZyB5b3Ugbm90aWNlPC9wPg0K PHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+dnMuPC9wPg0K PGgyIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDog bm9ybWFsIj5jb2zCt2xlY3Q8ZW0+IHZlcmI8L2VtPiBca8mZLcuIbGVrdFw8L3NwYW4+DQo8L2gy Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjogdG8gZ2V0ICh0aGluZ3Mp IGZyb20gZGlmZmVyZW50IHBsYWNlcyBhbmQgYnJpbmcgdGhlbSB0b2dldGhlcjwvcD4NCjxwIHN0 eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjogdG8gZ2V0IChvbmUgb3IgbW9yZSB0aGluZ3MpIGZy b20gYSBwbGFjZTwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29O b3JtYWwiPjogdG8gZ2V0IChzaW1pbGFyIHRoaW5ncykgYW5kIGJyaW5nIHRoZW0gdG9nZXRoZXIg YXMgYSBob2JieTwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIHN0eWxlPSJNQVJHSU4t TEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBsYXR0ZXIgc2VlbXMgYXMgbW9yZSBz dWl0YWJsZSBpbiBjaGFyYWN0ZXJpemF0aW9uIG9mIHJvbGUgb2YgTUEocykgaW4gZXhlY3V0aW5n IFBhc3NpdmUgTWVhc3VyZW1lbnQgbWV0aG9kcy48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJNQVJH SU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogMC41aW47IE1BUkdJTi1SSUdIVDogMGluIiBj bGFzcz0iTXNvTm9ybWFsIj4NClJFOiBNZWFzdXJlbWVudCBEb21haW4uIEdpdmVuIGVhcmxpZXIg ZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbiB0byB0YWtlIGhvbGlzdGljIGFwcHJvYWNoIHRvIE1B L01QIHJvbGUsIEkgYmVsaWV2ZSB3ZSBhcmUgYXQgdGhlIHBvaW50IHdoZXJlIGRpc2N1c3Npb24g b2YgTWVhc3VyZW1lbnQgRG9tYWluJ3MgZGVmaW5pdGlvbiBhbmQgdXNlIGlzIHRpbWVseSBhbmQg YXBwcm9wcmlhdGUuPC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1M RUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogMC41aW47IE1BUkdJTi1S SUdIVDogMGluIiBjbGFzcz0iTXNvTm9ybWFsIj4NCiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBzdHls ZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biA0LCAy MDE0IGF0IDg6MzQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29t Ij5waGlsaXAuZWFyZGxleUBidC5jb208L2E+Jmd0OyB3cm90ZTo8L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJs YWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6ICNjY2NjY2MgMXB0IHNvbGlkOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDZwdDsgUEFERElORy1SSUdIVDogMGluOyBNQVJHSU4tTEVGVDogNC44cHQ7 IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBNQVJHSU4tUklHSFQ6IDBpbjsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9 IkVOLUdCIj5Qcm9wb3NhbDotPC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41 aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tR0IiPkluIHRoZSBJbnRybywgYWRk IHRvIHRoZSBwYXJhZ3JhcGggYWJvdXQgQWN0aXZlICZhbXA7IFBhc3NpdmUgVGFza3M6PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZB TUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBw dCIgbGFuZz0iRU4tR0IiPlRoZXJlIG1heSBhbHNvIGJlIE1lYXN1cmVtZW50IFRhc2tzIHRoYXQg YXJlIGludGVybWVkaWF0ZSBiZXR3ZWVuIFBhc3NpdmUgYW5kIEFjdGl2ZSBvbmVzOyBjb25zaWRl cmF0aW9uIGlzIG91dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3JrDQogc2NvcGUuPC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIg bGFuZz0iRU4tR0IiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAu NWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLUdCIj5JbiB0ZXJtaW5vbG9neSwg dHdlYWsgdGhlIGRlZmluaXRpb25zOi08L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZU OiAwLjVpbiI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7 IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1HQiI+UGFzc2l2ZSBNZWFz dXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBB Z2VudCBvYnNlcnZlcyBleGlzdGluZyB0cmFmZmljIGJ1dCBkb2VzIG5vdCBpbmplY3QgQWN0aXZl IE1lYXN1cmVtZW50DQogVHJhZmZpYy48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZU OiAwLjVpbiI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7 IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1HQiI+R0lNJmd0OyZndDsg SSB0aGluayB0aGF0ICZxdW90O29ic2VydmVzJnF1b3Q7IGlzIG5vdCB0aGUgc2FtZSBhcyAmcXVv dDtjb2xsZWN0IGluZm9ybWF0aW9uIG9mZiZxdW90Oy4gQ2FuIGl0IGJlICZxdW90Oy4uLiBpbiB3 aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uDQogb2ZmIGV4aXN0 aW5nIHRyYWZmaWMgLi4uJnF1b3Q7PyBJIHRoaW5rIHRoYXQgYSBNZWFzdXJlbWVudCBBZ2VudCBt YXkgY29vcmRpbmF0ZSBpdHMgYWN0aW9ucyBpbiBwZXJmb3JtaW5nIFBhc3NpdmUgTWVhc3VyZW1l bnQgVGFzayB3aXRoIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4gTW9yZSBvbiBpdCBi ZWxvdy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAw LjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21h Jywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1H QiI+PC9zcGFuPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1B UkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0 IiBsYW5nPSJFTi1HQiI+W3BoaWxdIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCBkaWZm ZXJlbmNlIHlvdSdyZSBnZXR0aW5nIGF0IC0gd2hhdCBtZWFuaW5nIGRvIHlvdSB3YW50IHRvIGNv bnZleSB3aXRoICZxdW90O2NvbGxlY3QNCiBpbmZvcm1hdGlvbiZxdW90OyB0aGF0IGRpZmZlcnMg ZnJvbSAmcXVvdDtvYnNlcnZlcyZxdW90Oz88L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM WTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIg bGFuZz0iRU4tR0IiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAu NWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09M T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLUdCIj5BY3RpdmUgTWVhc3VyZW1l bnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQg c2VuZHMgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgdG8sIG9yIHJlY2VpdmVzIGl0IGZyb20s IG9uZQ0KIG9yIG1vcmUgb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRzIG9yIE1lYXN1cmVtZW50IFBl ZXJzLCBhbmQgcGVyaGFwcyBjb29yZGluYXRlcyB3aXRoIHRoZW0gdXNpbmcgcHJvdG9jb2xzIG91 dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiAjY2NjY2NjIDFwdCBzb2xpZDsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiA2cHQ7IFBBRERJTkctUklHSFQ6IDBp bjsgTUFSR0lOLUxFRlQ6IDQuOHB0OyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgTUFSR0lOLVJJ R0hUOiAwaW47IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAwaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDEwcHQiIGxhbmc9IkVOLUdCIj5HSU0mZ3Q7Jmd0OyBJcyAmcXVvdDtBY3RpdmUgTWVhc3Vy ZW1lbnQgVHJhZmZpYyZxdW90OyB0aGUgc2FtZSBhcyAmcXVvdDtUZXN0IFRyYWZmaWMmcXVvdDs/ IEFuZCBJJ2QgbGlrZSB0byBkaXNjdXNzIG5ldyBNZWFzdXJlbWVudCBEb21haW4gb2JqZWN0IGRl ZmluZWQgYXM6Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiAjY2NjY2NjIDFwdCBzb2xpZDsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiA2cHQ7IFBBRERJTkctUklHSFQ6IDBpbjsgTUFSR0lOLUxFRlQ6IDQuOHB0OyBCT1JERVItVE9Q OiBtZWRpdW0gbm9uZTsgTUFSR0lOLVJJR0hUOiAwaW47IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxF RlQ6IDAuNWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm JzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLUdCIj5UaGUgY29tbXVu aXR5IG9mIE1lYXN1cmVtZW50IEFnZW50cyBhbmQgTWVhc3VyZW1lbnQgUGVlcnMgdGhhdCBjb29w ZXJhdGUgaW4gcGVyZm9ybWluZyBhIE1lYXN1cmVtZW50IFRhc2ssIHdoZXRoZXIgQWN0aXZlIG9y IFBhc3NpdmUsDQogcHJlc2VudCBhIE1lYXN1cmVtZW50IERvbWFpbi4gQ29vcmRpbmF0aW9uIHBy b3RvY29sKHMpIHVzZWQgd2l0aGluIE1lYXN1cmVtZW50IERvbWFpbiBhcmUgb3V0c2lkZSBvZiB0 aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij5UaGVuIGluIGRlZmluaXRpb25zIG9m IEFjdGl2ZS9QYXNzaXZlIE1lYXN1cmVtZW50IFRhc2sgaW4gdGhlIExNQVAgRnJhbWV3b3JrIHdl IGNhbiB1c2UgdGhlIE1lYXN1cmVtZW50IERvbWFpbiBsaWtlOjxicj4NClBhc3NpdmUgTWVhc3Vy ZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdl bnQgY29sbGVjdHMgaW5mb3JtYXRpb24gb2ZmIGV4aXN0aW5nIHRyYWZmaWMgd2l0aGluIGl0cyBN ZWFzdXJlbWVudCBEb21haW4uPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNr OyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsg Rk9OVC1TSVpFOiAxMHB0Ij5bcGhpbF0geWVzLCBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyBp cyB3aGF0IHlvdSBjb3VsZCBjYWxsIHRlc3QgdHJhZmZpYyBbJnF1b3Q7QWN0aXZlIE1lYXN1cmVt ZW50IFRyYWZmaWM6IHRoZSBwYWNrZXQocykgZ2VuZXJhdGVkDQogaW4gb3JkZXIgdG8mbmJzcDtl eGVjdXRlIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiZxdW90O108L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm JzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6 IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPltwaGlsXSByZSBtZWFzdXJlbWVudCBkb21haW4gLSBp IGNhbiBzZWUgdGhpcyBtYXkgYmUgYSB1c2VmdWwgY29uY2VwdCwgYnV0IGkgZG9uJ3QgdGhpbmsg d2UndmUgbmVlZGVkIHRoaXMgdGVybSB5ZXQgaW4gbG1hcC4gZ2l2ZW4NCiBob3cgdHJpY2t5IGFn cmVlaW5nIHRlcm1pbm9sb2d5IGlzLCBjYW4gd2UgZGVsYXkgZGVmaW5pbmcgdGhpcyB0ZXJtIHVu dGlsIHdlJ3JlIHN1cmUgd2UgbmVlZCBpdC48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg c3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1T SVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1B UkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0 Ij50aGFua3M8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZU OiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFo b21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij5waGlsPC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419EMV67UKRDdoma_-- From nobody Thu Jun 5 02:49: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 E5AE71A0422 for ; Thu, 5 Jun 2014 02:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.651, 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 qBBZ_tQ2TMy9 for ; Thu, 5 Jun 2014 02:49:36 -0700 (PDT) Received: from mailrelay.usj.edu.lb (mailrelay.usj.edu.lb [193.227.187.142]) by ietfa.amsl.com (Postfix) with ESMTP id 51D771A041D for ; Thu, 5 Jun 2014 02:49:35 -0700 (PDT) X-ASG-Debug-ID: 1401962024-05fac16672ae8f0001-CueDvo Received: from Citrus.usj.edu.lb (rectorat2.usj.edu.lb [193.227.187.140]) by mailrelay.usj.edu.lb with ESMTP id 4rf2HcRCpMDLMD71; Thu, 05 Jun 2014 12:53:44 +0300 (EEST) X-Barracuda-Envelope-From: marc.ibrahim@usj.edu.lb X-Barracuda-Apparent-Source-IP: 193.227.187.140 Received: from marcHP ([172.25.1.173]) by Citrus.usj.edu.lb (8.13.8/8.13.8) with ESMTP id s559msWK028885; Thu, 5 Jun 2014 12:48:56 +0300 From: "Marc Ibrahim" To: , , References: , In-Reply-To: Date: Thu, 5 Jun 2014 12:48:52 +0300 X-ASG-Orig-Subj: RE: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Message-ID: <06a401cf80a3$68b9def0$3a2d9cd0$@usj.edu.lb> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06A5_01CF80BC.8E163220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHJqZoFJEdV5dH5oN6+i6XUPfitAKi5ibzAdHCTs0C+EKkDQIcJGyCAp1CiSiaEcIHEA== Content-Language: en-us X-Barracuda-Connect: rectorat2.usj.edu.lb[193.227.187.140] X-Barracuda-Start-Time: 1401962024 X-Barracuda-URL: http://mailrelay.usj.edu.lb:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at usj.edu.lb X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.6398 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/yMr-49LGZ6_ufbq5zDT23CHSf-w Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:49:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06A5_01CF80BC.8E163220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 Trevor has already proposed this kind of flag in a previous discussion = about suppression. It was proposed to avoid suppressing main control = tasks at MA. I agree that this flag solves the problem of default suppression = behavior. =20 I am just wondering if this flag should be present at the method or task = level.=20 =20 BR, =20 Marc. =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Thursday, June 05, 2014 12:13 PM To: KEN.KO@adtran.com; gregimirsky@gmail.com Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt =20 i think this is a very good suggestion. i agree this is the right way of = separating policy and protocol =20 as a side benefit, we can then drop the active vs passive distinction = (and terminology) (and do some slight rephrasing in the privacy section, = which is the main place that uses the terms) =20 thanks phil =20 _____ =20 From: KEN KO [KEN.KO@adtran.com] Sent: 05 June 2014 00:03 To: Greg Mirsky; Eardley,PL,Philip,TUB8 R Cc: lmap@ietf.org Subject: RE: [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt As I read this email thread which is similar to earlier ones discussing = active vs. passive, I keep thinking about the only place the distinction = is being used in the lmap framework, which is for suppression. And, I = keep thinking that we are creating a distinction the details of which we = cannot agree on, and that different test system operators intend to use = in different ways. And this leads me to think that there is a better way = to provide the agreed suppression behavior while allowing test system = operators to modify it as they wish. =20 Default suppression behavior, as specified in framework-05:=20 =20 =E2=80=9CSuppression means that the MA does not begin any new Active Measurement Task. The impact on other Measurement Tasks is not defined by LMAP; since they do not involve the MA creating any Active Measurement Traffic there is no need to suppress them, however it may be simpler for an implementation to do so.=E2=80=9D =20 We have arrived at this point because stakeholders could not agree on = how to treat Passive Tasks. As a result, some operators may suppress = Passive Tasks by default and others may let them continue, with = variations between those two extremes. And yet, since we are still = debating where to draw the line between Active and Passive, the matter = is not settled. =20 There is a better way. Simply add a field =E2=80=93 a Boolean true/false = flag is all that is required =E2=80=93 to the Measurement Task = Configuration indicating whether that Task is to be suppressed by = default. It shortcuts the Active Passive arguments (at least, in lmap) = and gives operators complete freedom over default suppression behavior. =20 The description of a Measurement Method in a registry could contain a = recommended value for the flag. However, operators would be free to use = that value or override it in their deployments. =20 Comments? =20 Ken =20 =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Wednesday, June 04, 2014 10:40 AM To: philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt =20 Hi Phil, thank you for your prompt response to my comments. if I compare common interpretations of "observe" and "collect": ob=C2=B7serve verb \=C9=99b-=CB=88z=C9=99rv\=20 : to watch and sometimes also listen to (someone or something) carefully : to see and notice (someone or something) : to make a comment about something you notice vs. col=C2=B7lect verb \k=C9=99-=CB=88lekt\=20 : to get (things) from different places and bring them together : to get (one or more things) from a place : to get (similar things) and bring them together as a hobby the latter seems as more suitable in characterization of role of MA(s) = in executing Passive Measurement methods. RE: Measurement Domain. Given earlier discussion and suggestion to take = holistic approach to MA/MP role, I believe we are at the point where = discussion of Measurement Domain's definition and use is timely and = appropriate. Regards, Greg =20 On Wed, Jun 4, 2014 at 8:34 AM, wrote: =20 Proposal:- In the Intro, add to the paragraph about Active & Passive Tasks: There may also be Measurement Tasks that are intermediate between = Passive and Active ones; consideration is outside the initial LMAP work = scope. =20 In terminology, tweak the definitions:- Passive Measurement Task: A Measurement Task in which a Measurement = Agent observes existing traffic but does not inject Active Measurement = Traffic. GIM>> I think that "observes" is not the same as "collect information = off". Can it be "... in which a Measurement Agent collects information = off existing traffic ..."? I think that a Measurement Agent may = coordinate its actions in performing Passive Measurement Task with other = Measurement Agents/Peers. More on it below. =20 [phil] I don't really understand what difference you're getting at - = what meaning do you want to convey with "collect information" that = differs from "observes"? =20 Active Measurement Task: A Measurement Task in which a Measurement Agent = sends Active Measurement Traffic to, or receives it from, one or more = other Measurement Agents or Measurement Peers, and perhaps coordinates = with them using protocols outside the initial LMAP work scope GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And = I'd like to discuss new Measurement Domain object defined as:=20 The community of Measurement Agents and Measurement Peers that cooperate = in performing a Measurement Task, whether Active or Passive, present a = Measurement Domain. Coordination protocol(s) used within Measurement = Domain are outside of the initial LMAP work scope. Then in definitions of Active/Passive Measurement Task in the LMAP = Framework we can use the Measurement Domain like: Passive Measurement Task: A Measurement Task in which a Measurement = Agent collects information off existing traffic within its Measurement = Domain. =20 [phil] yes, Active Measurement Traffic is what you could call test = traffic ["Active Measurement Traffic: the packet(s) generated in order = to execute an Active Measurement Task."] =20 [phil] re measurement domain - i can see this may be a useful concept, = but i don't think we've needed this term yet in lmap. given how tricky = agreeing terminology is, can we delay defining this term until we're = sure we need it. =20 thanks phil =20 ------=_NextPart_000_06A5_01CF80BC.8E163220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Trevor has already proposed this kind of flag in a previous = discussion about suppression. It was proposed to avoid suppressing main = control tasks at MA.

I agree that this flag solves the problem of default suppression = behavior.

 

I am just wondering if this flag should be present at the method or = task level.

 

BR,

 

Marc.

 

From:= = lmap [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: Thursday, June 05, 2014 12:13 = PM
To: KEN.KO@adtran.com; gregimirsky@gmail.com
Cc: = lmap@ietf.org
Subject: Re: [lmap] Follow-up on recent = discussion about = draft-ietf-lmap-framework-05.txt

 

= i think this is a very good suggestion. i agree this is the right way of = separating policy and protocol

=  

= as a side benefit, we can then drop the active vs passive distinction = (and terminology) (and do some slight rephrasing in the privacy section, = which is the main place that uses the = terms)

=  

= thanks

= phil

=  

=

= From:= KEN KO [KEN.KO@adtran.com]
Sent: 05 June 2014 = 00:03
To: Greg Mirsky; Eardley,PL,Philip,TUB8 R
Cc: = lmap@ietf.org
Subject: = RE: [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt

As I read this email thread which is similar to earlier ones = discussing active vs. passive, I keep thinking about the only place the = distinction is being used in the lmap framework, which is for = suppression. And, I keep thinking that we are creating a distinction the = details of which we cannot agree on, and that different test system = operators  intend to use in different ways. And this leads me to = think that there is a better way to provide the agreed suppression = behavior while allowing test system operators to modify it as they = wish.

 

Default suppression behavior, as specified in framework-05: =

 

=E2=80=9CSuppression means that the MA does not begin any = new

Active Measurement Task. The impact on other Measurement Tasks = is

not defined by LMAP; since they do not involve the MA creating = any

Active Measurement Traffic there is no need to suppress them, = however

it may be simpler for an implementation to do = so.=E2=80=9D

 

We have arrived at this point because stakeholders could not agree on = how to treat Passive Tasks. As a result, some operators may suppress = Passive Tasks by default and others may let them continue, with = variations between those two extremes. And yet, since we are still = debating where to draw the line between Active and Passive, the matter = is not settled.

 

There is a better way. Simply add a field =E2=80=93 a Boolean = true/false flag is all that is required =E2=80=93 to the Measurement = Task Configuration indicating whether that Task is to be suppressed by = default. It shortcuts the Active Passive arguments (at least, in lmap) = and gives operators complete freedom over default suppression = behavior.

 

The description of a Measurement Method in a registry could contain a = recommended value for the flag. However, operators would be free to use = that value or override it in their deployments.

 

Comments?

 

Ken

 

 

= From:= lmap [mailto:lmap-bounces@ietf.org] = On Behalf Of Greg Mirsky
Sent: Wednesday, June 04, 2014 = 10:40 AM
To: philip.eardley@bt.com
Cc:= lmap@ietf.org
Subject: Re: = [lmap] Follow-up on recent discussion about = draft-ietf-lmap-framework-05.txt

 

Hi Phil,

thank you for your prompt response to my = comments.

if I compare = common interpretations of "observe" and = "collect":

ob=C2=B7serve verb = \=C9=99b-=CB=88z=C9=99rv\ =

: to watch and sometimes also listen to (someone = or something) carefully

: to see and = notice (someone or something)

: to make a = comment about something you notice

vs.

col=C2=B7lect verb = \k=C9=99-=CB=88lekt\ =

: to get (things) from different places and bring = them together

: to get (one or more things) from a = place

: to get (similar = things) and bring them together as a = hobby

the latter seems = as more suitable in characterization of role of MA(s) in executing = Passive Measurement methods.

RE: Measurement Domain. Given = earlier discussion and suggestion to take holistic approach to MA/MP = role, I believe we are at the point where discussion of Measurement = Domain's definition and use is timely and = appropriate.

Regards,

Greg

 

On Wed, Jun 4, 2014 at 8:34 AM, <philip.eardley@bt.com> = wrote:

 

= Proposal:-

= In the Intro, add to the paragraph about Active & Passive = Tasks:

= There may also be Measurement Tasks that are intermediate between = Passive and Active ones; consideration is outside the initial LMAP work = scope.

 

= In terminology, tweak the definitions:-

= Passive Measurement Task: A Measurement Task in which a Measurement = Agent observes existing traffic but does not inject Active Measurement = Traffic.

= GIM>> I think that "observes" is not the same as = "collect information off". Can it be "... in which a = Measurement Agent collects information off existing traffic ..."? I = think that a Measurement Agent may coordinate its actions in performing = Passive Measurement Task with other Measurement Agents/Peers. More on it = below.

 

= [phil] I don't really understand what difference you're getting at - = what meaning do you want to convey with "collect information" = that differs from "observes"?

 

= Active Measurement Task: A Measurement Task in which a Measurement Agent = sends Active Measurement Traffic to, or receives it from, one or more = other Measurement Agents or Measurement Peers, and perhaps coordinates = with them using protocols outside the initial LMAP work = scope

= GIM>> Is "Active Measurement Traffic" the same as = "Test Traffic"? And I'd like to discuss new Measurement Domain = object defined as: 

= The community of Measurement Agents and Measurement Peers that cooperate = in performing a Measurement Task, whether Active or Passive, present a = Measurement Domain. Coordination protocol(s) used within Measurement = Domain are outside of the initial LMAP work scope.

= Then in definitions of Active/Passive Measurement Task in the LMAP = Framework we can use the Measurement Domain like:
Passive Measurement = Task: A Measurement Task in which a Measurement Agent collects = information off existing traffic within its Measurement = Domain.

 

= [phil] yes, Active Measurement Traffic is what you could call test = traffic ["Active Measurement Traffic: the packet(s) generated in = order to execute an Active Measurement Task."]

 

= [phil] re measurement domain - i can see this may be a useful concept, = but i don't think we've needed this term yet in lmap. given how tricky = agreeing terminology is, can we delay defining this term until we're = sure we need it.

 

= thanks

= phil

 

------=_NextPart_000_06A5_01CF80BC.8E163220-- From nobody Thu Jun 5 02:54:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462351A015A for ; Thu, 5 Jun 2014 02:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 DRHGalnU2eu7 for ; Thu, 5 Jun 2014 02:54:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A781A0151 for ; Thu, 5 Jun 2014 02:54:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4F8F51172; Thu, 5 Jun 2014 11:54:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XnbWQlVYvBrL; Thu, 5 Jun 2014 11:54:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jun 2014 11:54:17 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 563D220017; Thu, 5 Jun 2014 11:54:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 91BTZF7XM__m; Thu, 5 Jun 2014 11:54:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7639B20013; Thu, 5 Jun 2014 11:54:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38CF12D52178; Thu, 5 Jun 2014 11:54:16 +0200 (CEST) Date: Thu, 5 Jun 2014 11:54:15 +0200 From: Juergen Schoenwaelder To: Marc Ibrahim Message-ID: <20140605095415.GE11255@elstar.local> Mail-Followup-To: Marc Ibrahim , philip.eardley@bt.com, KEN.KO@adtran.com, gregimirsky@gmail.com, lmap@ietf.org References: <06a401cf80a3$68b9def0$3a2d9cd0$@usj.edu.lb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06a401cf80a3$68b9def0$3a2d9cd0$@usj.edu.lb> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/SD13OTSsXCbeHZRs25tJ8d2YqnM Cc: gregimirsky@gmail.com, philip.eardley@bt.com, KEN.KO@adtran.com, lmap@ietf.org Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:54:27 -0000 On Thu, Jun 05, 2014 at 12:48:52PM +0300, Marc Ibrahim wrote: > > I am just wondering if this flag should be present at the method or task level. > I believe LMAP only has tasks (or should only have tasks). /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 Jun 5 05:35: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 D480A1A00BA for ; Thu, 5 Jun 2014 05:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 FPsYSy2tFEIZ for ; Thu, 5 Jun 2014 05:35:17 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B201A0097 for ; Thu, 5 Jun 2014 05:35:16 -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 ef360935.2ae61ce9a940.9607309.00-2452.26441407.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Jun 2014 12:35:10 +0000 (UTC) X-MXL-Hash: 539063fe07fd8f22-b9a7f90ce81dec6df27efec5a5dc1d4cd0ae04f6 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 6f360935.0.9607183.00-2370.26440990.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 05 Jun 2014 12:35:03 +0000 (UTC) X-MXL-Hash: 539063f76afadac5-c33a472d562554d8356bfc62410d13bd6693a8d0 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 s55CZ1Ag016533; Thu, 5 Jun 2014 08:35:02 -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 s55CYpj9016466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 08:34:57 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 5 Jun 2014 12:34:40 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 08:34:39 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "KEN.KO@adtran.com" , "gregimirsky@gmail.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: AQHPfojkbNHfyGX67kmnH/9tHgk7xZthWtoAgAASfQCAAGr5AIAAqnaA///1EuA= Date: Thu, 5 Jun 2014 12:34:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6768@GAALPA1MSGUSRBF.ITServices.sbc.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.70.133.103] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE6768GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=4KGvShVWWqUA:10 a=ofMgfj31e3cA:10 a=5J7jPVQL82wA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=e9qsufxtAAAA:8 a=eJNrpioGAAAA:8 a=pGLkceISAAAA:8 a] X-AnalysisOut: [=NmISpzTwwaaKqYbtOcgA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:1] X-AnalysisOut: [0 a=W1qU_X6G3J8A:10 a=DvnSUQUdWHYA:10 a=MSl-tDqOz04A:10 a=] X-AnalysisOut: [g_6aMhtE2xKt82-O:21 a=qlHzduURJfAf4PKC:21 a=yMhMjlubAAAA:8] X-AnalysisOut: [ a=SSmOFEACAAAA:8 a=7d2Vj_3sIuZxsLWZw4gA:9 a=gKO2Hq4RSVkA:] X-AnalysisOut: [10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a] X-AnalysisOut: [=y7O5xpnRk5HfBnHj:21 a=lUKifvgFQO8DIiSh:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jKHrJyNQm2PmC0QL4HJwIczBV0k Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:35:20 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE6768GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCkJhcmJhcmENCg0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIHBoaWxpcC5lYXJkbGV5QGJ0LmNvbQ0KU2VudDogVGh1cnNkYXksIEp1bmUg MDUsIDIwMTQgNToxMyBBTQ0KVG86IEtFTi5LT0BhZHRyYW4uY29tOyBncmVnaW1pcnNreUBnbWFp bC5jb20NCkNjOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xtYXBdIEZvbGxvdy11cCBv biByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4 dA0KDQppIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IGdvb2Qgc3VnZ2VzdGlvbi4gaSBhZ3JlZSB0aGlz IGlzIHRoZSByaWdodCB3YXkgb2Ygc2VwYXJhdGluZyBwb2xpY3kgYW5kIHByb3RvY29sDQoNCmFz IGEgc2lkZSBiZW5lZml0LCB3ZSBjYW4gdGhlbiBkcm9wIHRoZSBhY3RpdmUgdnMgcGFzc2l2ZSBk aXN0aW5jdGlvbiAoYW5kIHRlcm1pbm9sb2d5KSAoYW5kIGRvIHNvbWUgc2xpZ2h0IHJlcGhyYXNp bmcgaW4gdGhlIHByaXZhY3kgc2VjdGlvbiwgd2hpY2ggaXMgdGhlIG1haW4gcGxhY2UgdGhhdCB1 c2VzIHRoZSB0ZXJtcykNCg0KdGhhbmtzDQpwaGlsDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBLRU4gS08gW0tFTi5LT0BhZHRyYW4uY29tXQ0KU2VudDogMDUgSnVu ZSAyMDE0IDAwOjAzDQpUbzogR3JlZyBNaXJza3k7IEVhcmRsZXksUEwsUGhpbGlwLFRVQjggUg0K Q2M6IGxtYXBAaWV0Zi5vcmc8bWFpbHRvOmxtYXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW2xt YXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRmLWxtYXAt ZnJhbWV3b3JrLTA1LnR4dA0KQXMgSSByZWFkIHRoaXMgZW1haWwgdGhyZWFkIHdoaWNoIGlzIHNp bWlsYXIgdG8gZWFybGllciBvbmVzIGRpc2N1c3NpbmcgYWN0aXZlIHZzLiBwYXNzaXZlLCBJIGtl ZXAgdGhpbmtpbmcgYWJvdXQgdGhlIG9ubHkgcGxhY2UgdGhlIGRpc3RpbmN0aW9uIGlzIGJlaW5n IHVzZWQgaW4gdGhlIGxtYXAgZnJhbWV3b3JrLCB3aGljaCBpcyBmb3Igc3VwcHJlc3Npb24uIEFu ZCwgSSBrZWVwIHRoaW5raW5nIHRoYXQgd2UgYXJlIGNyZWF0aW5nIGEgZGlzdGluY3Rpb24gdGhl IGRldGFpbHMgb2Ygd2hpY2ggd2UgY2Fubm90IGFncmVlIG9uLCBhbmQgdGhhdCBkaWZmZXJlbnQg dGVzdCBzeXN0ZW0gb3BlcmF0b3JzICBpbnRlbmQgdG8gdXNlIGluIGRpZmZlcmVudCB3YXlzLiBB bmQgdGhpcyBsZWFkcyBtZSB0byB0aGluayB0aGF0IHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBw cm92aWRlIHRoZSBhZ3JlZWQgc3VwcHJlc3Npb24gYmVoYXZpb3Igd2hpbGUgYWxsb3dpbmcgdGVz dCBzeXN0ZW0gb3BlcmF0b3JzIHRvIG1vZGlmeSBpdCBhcyB0aGV5IHdpc2guDQoNCkRlZmF1bHQg c3VwcHJlc3Npb24gYmVoYXZpb3IsIGFzIHNwZWNpZmllZCBpbiBmcmFtZXdvcmstMDU6DQoNCuKA nFN1cHByZXNzaW9uIG1lYW5zIHRoYXQgdGhlIE1BIGRvZXMgbm90IGJlZ2luIGFueSBuZXcNCkFj dGl2ZSBNZWFzdXJlbWVudCBUYXNrLiBUaGUgaW1wYWN0IG9uIG90aGVyIE1lYXN1cmVtZW50IFRh c2tzIGlzDQpub3QgZGVmaW5lZCBieSBMTUFQOyBzaW5jZSB0aGV5IGRvIG5vdCBpbnZvbHZlIHRo ZSBNQSBjcmVhdGluZyBhbnkNCkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIHRoZXJlIGlzIG5v IG5lZWQgdG8gc3VwcHJlc3MgdGhlbSwgaG93ZXZlcg0KaXQgbWF5IGJlIHNpbXBsZXIgZm9yIGFu IGltcGxlbWVudGF0aW9uIHRvIGRvIHNvLuKAnQ0KDQpXZSBoYXZlIGFycml2ZWQgYXQgdGhpcyBw b2ludCBiZWNhdXNlIHN0YWtlaG9sZGVycyBjb3VsZCBub3QgYWdyZWUgb24gaG93IHRvIHRyZWF0 IFBhc3NpdmUgVGFza3MuIEFzIGEgcmVzdWx0LCBzb21lIG9wZXJhdG9ycyBtYXkgc3VwcHJlc3Mg UGFzc2l2ZSBUYXNrcyBieSBkZWZhdWx0IGFuZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVl LCB3aXRoIHZhcmlhdGlvbnMgYmV0d2VlbiB0aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNp bmNlIHdlIGFyZSBzdGlsbCBkZWJhdGluZyB3aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4g QWN0aXZlIGFuZCBQYXNzaXZlLCB0aGUgbWF0dGVyIGlzIG5vdCBzZXR0bGVkLg0KDQpUaGVyZSBp cyBhIGJldHRlciB3YXkuIFNpbXBseSBhZGQgYSBmaWVsZCDigJMgYSBCb29sZWFuIHRydWUvZmFs c2UgZmxhZyBpcyBhbGwgdGhhdCBpcyByZXF1aXJlZCDigJMgdG8gdGhlIE1lYXN1cmVtZW50IFRh c2sgQ29uZmlndXJhdGlvbiBpbmRpY2F0aW5nIHdoZXRoZXIgdGhhdCBUYXNrIGlzIHRvIGJlIHN1 cHByZXNzZWQgYnkgZGVmYXVsdC4gSXQgc2hvcnRjdXRzIHRoZSBBY3RpdmUgUGFzc2l2ZSBhcmd1 bWVudHMgKGF0IGxlYXN0LCBpbiBsbWFwKSBhbmQgZ2l2ZXMgb3BlcmF0b3JzIGNvbXBsZXRlIGZy ZWVkb20gb3ZlciBkZWZhdWx0IHN1cHByZXNzaW9uIGJlaGF2aW9yLg0KDQpUaGUgZGVzY3JpcHRp b24gb2YgYSBNZWFzdXJlbWVudCBNZXRob2QgaW4gYSByZWdpc3RyeSBjb3VsZCBjb250YWluIGEg cmVjb21tZW5kZWQgdmFsdWUgZm9yIHRoZSBmbGFnLiBIb3dldmVyLCBvcGVyYXRvcnMgd291bGQg YmUgZnJlZSB0byB1c2UgdGhhdCB2YWx1ZSBvciBvdmVycmlkZSBpdCBpbiB0aGVpciBkZXBsb3lt ZW50cy4NCg0KQ29tbWVudHM/DQoNCktlbg0KDQoNCkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDogV2VkbmVzZGF5 LCBKdW5lIDA0LCAyMDE0IDEwOjQwIEFNDQpUbzogcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1haWx0 bzpwaGlsaXAuZWFyZGxleUBidC5jb20+DQpDYzogbG1hcEBpZXRmLm9yZzxtYWlsdG86bG1hcEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbG1hcF0gRm9sbG93LXVwIG9uIHJlY2VudCBkaXNjdXNz aW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0DQoNCkhpIFBoaWwsDQp0 aGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlIHRvIG15IGNvbW1lbnRzLg0KaWYgSSBj b21wYXJlIGNvbW1vbiBpbnRlcnByZXRhdGlvbnMgb2YgIm9ic2VydmUiIGFuZCAiY29sbGVjdCI6 DQpvYsK3c2VydmUgdmVyYiBcyZliLcuIesmZcnZcDQoNCjogdG8gd2F0Y2ggYW5kIHNvbWV0aW1l cyBhbHNvIGxpc3RlbiB0byAoc29tZW9uZSBvciBzb21ldGhpbmcpIGNhcmVmdWxseQ0KDQo6IHRv IHNlZSBhbmQgbm90aWNlIChzb21lb25lIG9yIHNvbWV0aGluZykNCjogdG8gbWFrZSBhIGNvbW1l bnQgYWJvdXQgc29tZXRoaW5nIHlvdSBub3RpY2UNCnZzLg0KY29swrdsZWN0IHZlcmIgXGvJmS3L iGxla3RcDQoNCjogdG8gZ2V0ICh0aGluZ3MpIGZyb20gZGlmZmVyZW50IHBsYWNlcyBhbmQgYnJp bmcgdGhlbSB0b2dldGhlcg0KDQo6IHRvIGdldCAob25lIG9yIG1vcmUgdGhpbmdzKSBmcm9tIGEg cGxhY2UNCjogdG8gZ2V0IChzaW1pbGFyIHRoaW5ncykgYW5kIGJyaW5nIHRoZW0gdG9nZXRoZXIg YXMgYSBob2JieQ0KdGhlIGxhdHRlciBzZWVtcyBhcyBtb3JlIHN1aXRhYmxlIGluIGNoYXJhY3Rl cml6YXRpb24gb2Ygcm9sZSBvZiBNQShzKSBpbiBleGVjdXRpbmcgUGFzc2l2ZSBNZWFzdXJlbWVu dCBtZXRob2RzLg0KUkU6IE1lYXN1cmVtZW50IERvbWFpbi4gR2l2ZW4gZWFybGllciBkaXNjdXNz aW9uIGFuZCBzdWdnZXN0aW9uIHRvIHRha2UgaG9saXN0aWMgYXBwcm9hY2ggdG8gTUEvTVAgcm9s ZSwgSSBiZWxpZXZlIHdlIGFyZSBhdCB0aGUgcG9pbnQgd2hlcmUgZGlzY3Vzc2lvbiBvZiBNZWFz dXJlbWVudCBEb21haW4ncyBkZWZpbml0aW9uIGFuZCB1c2UgaXMgdGltZWx5IGFuZCBhcHByb3By aWF0ZS4NClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgODozNCBBTSwg PHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tPj4gd3Jv dGU6DQoNCg0KUHJvcG9zYWw6LQ0KDQpJbiB0aGUgSW50cm8sIGFkZCB0byB0aGUgcGFyYWdyYXBo IGFib3V0IEFjdGl2ZSAmIFBhc3NpdmUgVGFza3M6DQoNClRoZXJlIG1heSBhbHNvIGJlIE1lYXN1 cmVtZW50IFRhc2tzIHRoYXQgYXJlIGludGVybWVkaWF0ZSBiZXR3ZWVuIFBhc3NpdmUgYW5kIEFj dGl2ZSBvbmVzOyBjb25zaWRlcmF0aW9uIGlzIG91dHNpZGUgdGhlIGluaXRpYWwgTE1BUCB3b3Jr IHNjb3BlLg0KDQoNCg0KSW4gdGVybWlub2xvZ3ksIHR3ZWFrIHRoZSBkZWZpbml0aW9uczotDQoN ClBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEg TWVhc3VyZW1lbnQgQWdlbnQgb2JzZXJ2ZXMgZXhpc3RpbmcgdHJhZmZpYyBidXQgZG9lcyBub3Qg aW5qZWN0IEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljLg0KDQpHSU0+PiBJIHRoaW5rIHRoYXQg Im9ic2VydmVzIiBpcyBub3QgdGhlIHNhbWUgYXMgImNvbGxlY3QgaW5mb3JtYXRpb24gb2ZmIi4g Q2FuIGl0IGJlICIuLi4gaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBjb2xsZWN0cyBpbmZv cm1hdGlvbiBvZmYgZXhpc3RpbmcgdHJhZmZpYyAuLi4iPyBJIHRoaW5rIHRoYXQgYSBNZWFzdXJl bWVudCBBZ2VudCBtYXkgY29vcmRpbmF0ZSBpdHMgYWN0aW9ucyBpbiBwZXJmb3JtaW5nIFBhc3Np dmUgTWVhc3VyZW1lbnQgVGFzayB3aXRoIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cy9QZWVycy4g TW9yZSBvbiBpdCBiZWxvdy4NCg0KW3BoaWxdIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hh dCBkaWZmZXJlbmNlIHlvdSdyZSBnZXR0aW5nIGF0IC0gd2hhdCBtZWFuaW5nIGRvIHlvdSB3YW50 IHRvIGNvbnZleSB3aXRoICJjb2xsZWN0IGluZm9ybWF0aW9uIiB0aGF0IGRpZmZlcnMgZnJvbSAi b2JzZXJ2ZXMiPw0KDQoNCg0KQWN0aXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQg VGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IHNlbmRzIEFjdGl2ZSBNZWFzdXJlbWVu dCBUcmFmZmljIHRvLCBvciByZWNlaXZlcyBpdCBmcm9tLCBvbmUgb3IgbW9yZSBvdGhlciBNZWFz dXJlbWVudCBBZ2VudHMgb3IgTWVhc3VyZW1lbnQgUGVlcnMsIGFuZCBwZXJoYXBzIGNvb3JkaW5h dGVzIHdpdGggdGhlbSB1c2luZyBwcm90b2NvbHMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdv cmsgc2NvcGUNCg0KR0lNPj4gSXMgIkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIiB0aGUgc2Ft ZSBhcyAiVGVzdCBUcmFmZmljIj8gQW5kIEknZCBsaWtlIHRvIGRpc2N1c3MgbmV3IE1lYXN1cmVt ZW50IERvbWFpbiBvYmplY3QgZGVmaW5lZCBhczoNCg0KVGhlIGNvbW11bml0eSBvZiBNZWFzdXJl bWVudCBBZ2VudHMgYW5kIE1lYXN1cmVtZW50IFBlZXJzIHRoYXQgY29vcGVyYXRlIGluIHBlcmZv cm1pbmcgYSBNZWFzdXJlbWVudCBUYXNrLCB3aGV0aGVyIEFjdGl2ZSBvciBQYXNzaXZlLCBwcmVz ZW50IGEgTWVhc3VyZW1lbnQgRG9tYWluLiBDb29yZGluYXRpb24gcHJvdG9jb2wocykgdXNlZCB3 aXRoaW4gTWVhc3VyZW1lbnQgRG9tYWluIGFyZSBvdXRzaWRlIG9mIHRoZSBpbml0aWFsIExNQVAg d29yayBzY29wZS4NClRoZW4gaW4gZGVmaW5pdGlvbnMgb2YgQWN0aXZlL1Bhc3NpdmUgTWVhc3Vy ZW1lbnQgVGFzayBpbiB0aGUgTE1BUCBGcmFtZXdvcmsgd2UgY2FuIHVzZSB0aGUgTWVhc3VyZW1l bnQgRG9tYWluIGxpa2U6DQpQYXNzaXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQg VGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uIG9m ZiBleGlzdGluZyB0cmFmZmljIHdpdGhpbiBpdHMgTWVhc3VyZW1lbnQgRG9tYWluLg0KDQpbcGhp bF0geWVzLCBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyBpcyB3aGF0IHlvdSBjb3VsZCBjYWxs IHRlc3QgdHJhZmZpYyBbIkFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljOiB0aGUgcGFja2V0KHMp IGdlbmVyYXRlZCBpbiBvcmRlciB0byBleGVjdXRlIGFuIEFjdGl2ZSBNZWFzdXJlbWVudCBUYXNr LiJdDQoNCltwaGlsXSByZSBtZWFzdXJlbWVudCBkb21haW4gLSBpIGNhbiBzZWUgdGhpcyBtYXkg YmUgYSB1c2VmdWwgY29uY2VwdCwgYnV0IGkgZG9uJ3QgdGhpbmsgd2UndmUgbmVlZGVkIHRoaXMg dGVybSB5ZXQgaW4gbG1hcC4gZ2l2ZW4gaG93IHRyaWNreSBhZ3JlZWluZyB0ZXJtaW5vbG9neSBp cywgY2FuIHdlIGRlbGF5IGRlZmluaW5nIHRoaXMgdGVybSB1bnRpbCB3ZSdyZSBzdXJlIHdlIG5l ZWQgaXQuDQoNCnRoYW5rcw0KcGhpbA0KDQo= --_000_2D09D61DDFA73D4C884805CC7865E61130DE6768GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAy IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5n IDIiOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJ Zm9udC13ZWlnaHQ6Ym9sZDt9DQpwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRp di5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOm1zb2NocGRlZmF1bHQ7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uaGVhZGluZzJjaGFyMA0KCXtt c28tc3R5bGUtbmFtZTpoZWFkaW5nMmNoYXI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJp ZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uZW1haWxzdHls ZTIwDQoJe21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUyMDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0Mzsx PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbG1hcCBbbWFpbHRvOmxtYXAtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+cGhpbGlwLmVhcmRsZXlAYnQuY29tPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0IDU6MTMgQU08YnI+DQo8Yj5Ubzo8L2I+ IEtFTi5LT0BhZHRyYW4uY29tOyBncmVnaW1pcnNreUBnbWFpbC5jb208YnI+DQo8Yj5DYzo8L2I+ IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtsbWFwXSBGb2xsb3ctdXAg b24gcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50 eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5pIHRoaW5rIHRo aXMgaXMgYSB2ZXJ5IGdvb2Qgc3VnZ2VzdGlvbi4gaSBhZ3JlZSB0aGlzIGlzIHRoZSByaWdodCB3 YXkgb2Ygc2VwYXJhdGluZyBwb2xpY3kgYW5kIHByb3RvY29sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5hcyBhIHNpZGUgYmVuZWZpdCwgd2UgY2FuIHRoZW4gZHJvcCB0aGUgYWN0 aXZlIHZzIHBhc3NpdmUgZGlzdGluY3Rpb24gKGFuZCB0ZXJtaW5vbG9neSkgKGFuZCBkbyBzb21l IHNsaWdodCByZXBocmFzaW5nIGluIHRoZSBwcml2YWN5IHNlY3Rpb24sIHdoaWNoIGlzIHRoZSBt YWluDQogcGxhY2UgdGhhdCB1c2VzIHRoZSB0ZXJtcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPnRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5waGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBGNjg2MDUiPg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBLRU4gS08gW0tFTi5LT0BhZHRyYW4uY29tXTxicj4N CjxiPlNlbnQ6PC9iPiAwNSBKdW5lIDIwMTQgMDA6MDM8YnI+DQo8Yj5Ubzo8L2I+IEdyZWcgTWly c2t5OyBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFI8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpsbWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1p ZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgSSByZWFkIHRoaXMgZW1haWwgdGhyZWFkIHdoaWNoIGlz IHNpbWlsYXIgdG8gZWFybGllciBvbmVzIGRpc2N1c3NpbmcgYWN0aXZlIHZzLiBwYXNzaXZlLCBJ IGtlZXAgdGhpbmtpbmcgYWJvdXQgdGhlIG9ubHkgcGxhY2UgdGhlIGRpc3RpbmN0aW9uIGlzIGJl aW5nIHVzZWQNCiBpbiB0aGUgbG1hcCBmcmFtZXdvcmssIHdoaWNoIGlzIGZvciBzdXBwcmVzc2lv bi4gQW5kLCBJIGtlZXAgdGhpbmtpbmcgdGhhdCB3ZSBhcmUgY3JlYXRpbmcgYSBkaXN0aW5jdGlv biB0aGUgZGV0YWlscyBvZiB3aGljaCB3ZSBjYW5ub3QgYWdyZWUgb24sIGFuZCB0aGF0IGRpZmZl cmVudCB0ZXN0IHN5c3RlbSBvcGVyYXRvcnMgJm5ic3A7aW50ZW5kIHRvIHVzZSBpbiBkaWZmZXJl bnQgd2F5cy4gQW5kIHRoaXMgbGVhZHMgbWUgdG8gdGhpbmsgdGhhdCB0aGVyZQ0KIGlzIGEgYmV0 dGVyIHdheSB0byBwcm92aWRlIHRoZSBhZ3JlZWQgc3VwcHJlc3Npb24gYmVoYXZpb3Igd2hpbGUg YWxsb3dpbmcgdGVzdCBzeXN0ZW0gb3BlcmF0b3JzIHRvIG1vZGlmeSBpdCBhcyB0aGV5IHdpc2gu PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVmYXVsdCBzdXBwcmVzc2lvbiBiZWhhdmlvciwg YXMgc3BlY2lmaWVkIGluIGZyYW1ld29yay0wNToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PuKAnFN1cHByZXNzaW9uIG1lYW5zIHRoYXQgdGhlIE1BIGRvZXMgbm90IGJlZ2luIGFueSBuZXc8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QWN0aXZlIE1lYXN1cmVtZW50IFRhc2suIFRoZSBpbXBhY3Qgb24gb3RoZXIgTWVhc3Vy ZW1lbnQgVGFza3MgaXM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+bm90IGRlZmluZWQgYnkgTE1BUDsgc2luY2UgdGhleSBkbyBu b3QgaW52b2x2ZSB0aGUgTUEgY3JlYXRpbmcgYW55PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjdGl2ZSBNZWFzdXJlbWVudCBU cmFmZmljIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3VwcHJlc3MgdGhlbSwgaG93ZXZlcjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5p dCBtYXkgYmUgc2ltcGxlciBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gc28u4oCdPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBhcnJpdmVkIGF0IHRoaXMgcG9pbnQgYmVjYXVz ZSBzdGFrZWhvbGRlcnMgY291bGQgbm90IGFncmVlIG9uIGhvdyB0byB0cmVhdCBQYXNzaXZlIFRh c2tzLiBBcyBhIHJlc3VsdCwgc29tZSBvcGVyYXRvcnMgbWF5IHN1cHByZXNzIFBhc3NpdmUgVGFz a3MgYnkNCiBkZWZhdWx0IGFuZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVlLCB3aXRoIHZh cmlhdGlvbnMgYmV0d2VlbiB0aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNpbmNlIHdlIGFy ZSBzdGlsbCBkZWJhdGluZyB3aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4gQWN0aXZlIGFu ZCBQYXNzaXZlLCB0aGUgbWF0dGVyIGlzIG5vdCBzZXR0bGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoZXJlIGlzIGEgYmV0dGVyIHdheS4gU2ltcGx5IGFkZCBhIGZpZWxkIOKAkyBhIEJv b2xlYW4gdHJ1ZS9mYWxzZSBmbGFnIGlzIGFsbCB0aGF0IGlzIHJlcXVpcmVkIOKAkyB0byB0aGUg TWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIGluZGljYXRpbmcgd2hldGhlciB0aGF0DQog VGFzayBpcyB0byBiZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuIEl0IHNob3J0Y3V0cyB0aGUgQWN0 aXZlIFBhc3NpdmUgYXJndW1lbnRzIChhdCBsZWFzdCwgaW4gbG1hcCkgYW5kIGdpdmVzIG9wZXJh dG9ycyBjb21wbGV0ZSBmcmVlZG9tIG92ZXIgZGVmYXVsdCBzdXBwcmVzc2lvbiBiZWhhdmlvci48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZGVzY3JpcHRpb24gb2YgYSBNZWFzdXJlbWVu dCBNZXRob2QgaW4gYSByZWdpc3RyeSBjb3VsZCBjb250YWluIGEgcmVjb21tZW5kZWQgdmFsdWUg Zm9yIHRoZSBmbGFnLiBIb3dldmVyLCBvcGVyYXRvcnMgd291bGQgYmUgZnJlZSB0byB1c2UgdGhh dCB2YWx1ZSBvcg0KIG92ZXJyaWRlIGl0IGluIHRoZWlyIGRlcGxveW1lbnRzLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktlbjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+IGxtYXAgWzxhIGhyZWY9Im1haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5H cmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgMTA6 NDAgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5j b20iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpsbWFwQGlldGYub3JnIj5sbWFwQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1p ZXRmLWxtYXAtZnJhbWV3b3JrLTA1LnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj50aGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlIHRvIG15IGNvbW1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+aWYgSSBj b21wYXJlIGNvbW1vbiBpbnRlcnByZXRhdGlvbnMgb2YgJnF1b3Q7b2JzZXJ2ZSZxdW90OyBhbmQg JnF1b3Q7Y29sbGVjdCZxdW90Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJoZWFk d29yZCI+DQo8aDIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjaztmb250LXdlaWdodDpub3JtYWwiPm9iwrdzZXJ2ZTxlbT4gdmVyYjwvZW0+IFzJmWIty4h6 yZlydlw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvaDI+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+OiB0byB3YXRjaCBhbmQgc29tZXRpbWVzIGFsc28gbGlzdGVuIHRvIChzb21l b25lIG9yIHNvbWV0aGluZykgY2FyZWZ1bGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiB0byBzZWUg YW5kIG5vdGljZSAoc29tZW9uZSBvciBzb21ldGhpbmcpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+OiB0byBtYWtlIGEgY29tbWVudCBhYm91dCBzb21ldGhpbmcgeW91IG5v dGljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnZzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxoMiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrO2ZvbnQtd2VpZ2h0Om5vcm1hbCI+Y29swrdsZWN0PGVtPiB2ZXJiPC9lbT4gXGvJ mS3LiGxla3RcPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L2gyPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjogdG8gZ2V0ICh0aGluZ3MpIGZyb20gZGlmZmVyZW50IHBsYWNlcyBh bmQgYnJpbmcgdGhlbSB0b2dldGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogdG8gZ2V0IChvbmUg b3IgbW9yZSB0aGluZ3MpIGZyb20gYSBwbGFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjogdG8gZ2V0IChzaW1pbGFyIHRoaW5ncykgYW5kIGJyaW5nIHRoZW0gdG9nZXRo ZXIgYXMgYSBob2JieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPnRoZSBsYXR0ZXIgc2VlbXMgYXMgbW9yZSBzdWl0YWJsZSBpbiBj aGFyYWN0ZXJpemF0aW9uIG9mIHJvbGUgb2YgTUEocykgaW4gZXhlY3V0aW5nIFBhc3NpdmUgTWVh c3VyZW1lbnQgbWV0aG9kcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlJFOiBNZWFzdXJlbWVudCBEb21haW4uIEdpdmVuIGVhcmxpZXIgZGlzY3Vz c2lvbiBhbmQgc3VnZ2VzdGlvbiB0byB0YWtlIGhvbGlzdGljIGFwcHJvYWNoIHRvIE1BL01QIHJv bGUsIEkgYmVsaWV2ZSB3ZSBhcmUgYXQgdGhlIHBvaW50IHdoZXJlIGRpc2N1c3Npb24gb2YgTWVh c3VyZW1lbnQgRG9tYWluJ3MgZGVmaW5pdGlvbiBhbmQgdXNlIGlzIHRpbWVseSBhbmQgYXBwcm9w cmlhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+R3JlZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PbiBX ZWQsIEp1biA0LCAyMDE0IGF0IDg6MzQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGlwLmVh cmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxleUBidC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UHJvcG9zYWw6LTwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkluIHRoZSBJbnRybywgYWRkIHRvIHRoZSBwYXJhZ3JhcGggYWJvdXQgQWN0 aXZlICZhbXA7IFBhc3NpdmUgVGFza3M6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlcmUgbWF5 IGFsc28gYmUgTWVhc3VyZW1lbnQgVGFza3MgdGhhdCBhcmUgaW50ZXJtZWRpYXRlIGJldHdlZW4g UGFzc2l2ZSBhbmQgQWN0aXZlIG9uZXM7IGNvbnNpZGVyYXRpb24gaXMgb3V0c2lkZSB0aGUgaW5p dGlhbCBMTUFQIHdvcmsgc2NvcGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SW4gdGVybWlub2xvZ3ksIHR3ZWFrIHRoZSBkZWZpbml0aW9uczotPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+UGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVt ZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBvYnNlcnZlcyBleGlzdGluZyB0 cmFmZmljIGJ1dCBkb2VzIG5vdCBpbmplY3QgQWN0aXZlIE1lYXN1cmVtZW50DQogVHJhZmZpYy48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgJnF1b3Q7b2Jz ZXJ2ZXMmcXVvdDsgaXMgbm90IHRoZSBzYW1lIGFzICZxdW90O2NvbGxlY3QgaW5mb3JtYXRpb24g b2ZmJnF1b3Q7LiBDYW4gaXQgYmUgJnF1b3Q7Li4uIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdl bnQgY29sbGVjdHMgaW5mb3JtYXRpb24NCiBvZmYgZXhpc3RpbmcgdHJhZmZpYyAuLi4mcXVvdDs/ IEkgdGhpbmsgdGhhdCBhIE1lYXN1cmVtZW50IEFnZW50IG1heSBjb29yZGluYXRlIGl0cyBhY3Rp b25zIGluIHBlcmZvcm1pbmcgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIHdpdGggb3RoZXIgTWVh c3VyZW1lbnQgQWdlbnRzL1BlZXJzLiBNb3JlIG9uIGl0IGJlbG93Ljwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+W3BoaWxd IEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCBkaWZmZXJlbmNlIHlvdSdyZSBnZXR0aW5n IGF0IC0gd2hhdCBtZWFuaW5nIGRvIHlvdSB3YW50IHRvIGNvbnZleSB3aXRoICZxdW90O2NvbGxl Y3QgaW5mb3JtYXRpb24mcXVvdDsNCiB0aGF0IGRpZmZlcnMgZnJvbSAmcXVvdDtvYnNlcnZlcyZx dW90Oz88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+QWN0aXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1l bnQgVGFzayBpbiB3aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IHNlbmRzIEFjdGl2ZSBNZWFzdXJl bWVudCBUcmFmZmljIHRvLCBvciByZWNlaXZlcyBpdCBmcm9tLCBvbmUgb3IgbW9yZQ0KIG90aGVy IE1lYXN1cmVtZW50IEFnZW50cyBvciBNZWFzdXJlbWVudCBQZWVycywgYW5kIHBlcmhhcHMgY29v cmRpbmF0ZXMgd2l0aCB0aGVtIHVzaW5nIHByb3RvY29scyBvdXRzaWRlIHRoZSBpbml0aWFsIExN QVAgd29yayBzY29wZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R0lNJmd0OyZndDsgSXMgJnF1b3Q7QWN0 aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMmcXVvdDsgdGhlIHNhbWUgYXMgJnF1b3Q7VGVzdCBUcmFm ZmljJnF1b3Q7PyBBbmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1lbnQgRG9tYWlu IG9iamVjdCBkZWZpbmVkIGFzOiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGNvbW11bml0eSBvZiBNZWFzdXJlbWVu dCBBZ2VudHMgYW5kIE1lYXN1cmVtZW50IFBlZXJzIHRoYXQgY29vcGVyYXRlIGluIHBlcmZvcm1p bmcgYSBNZWFzdXJlbWVudCBUYXNrLCB3aGV0aGVyIEFjdGl2ZSBvciBQYXNzaXZlLCBwcmVzZW50 DQogYSBNZWFzdXJlbWVudCBEb21haW4uIENvb3JkaW5hdGlvbiBwcm90b2NvbChzKSB1c2VkIHdp dGhpbiBNZWFzdXJlbWVudCBEb21haW4gYXJlIG91dHNpZGUgb2YgdGhlIGluaXRpYWwgTE1BUCB3 b3JrIHNjb3BlLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVuIGluIGRlZmluaXRpb25zIG9mIEFjdGl2ZS9QYXNzaXZl IE1lYXN1cmVtZW50IFRhc2sgaW4gdGhlIExNQVAgRnJhbWV3b3JrIHdlIGNhbiB1c2UgdGhlIE1l YXN1cmVtZW50IERvbWFpbiBsaWtlOjxicj4NClBhc3NpdmUgTWVhc3VyZW1lbnQgVGFzazogQSBN ZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgY29sbGVjdHMgaW5m b3JtYXRpb24gb2ZmIGV4aXN0aW5nIHRyYWZmaWMgd2l0aGluIGl0cyBNZWFzdXJlbWVudCBEb21h aW4uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPltwaGlsXSB5ZXMsIEFjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljIGlz IHdoYXQgeW91IGNvdWxkIGNhbGwgdGVzdCB0cmFmZmljIFsmcXVvdDtBY3RpdmUgTWVhc3VyZW1l bnQgVHJhZmZpYzogdGhlIHBhY2tldChzKSBnZW5lcmF0ZWQgaW4gb3JkZXINCiB0byZuYnNwO2V4 ZWN1dGUgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suJnF1b3Q7XTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5bcGhpbF0gcmUgbWVhc3VyZW1l bnQgZG9tYWluIC0gaSBjYW4gc2VlIHRoaXMgbWF5IGJlIGEgdXNlZnVsIGNvbmNlcHQsIGJ1dCBp IGRvbid0IHRoaW5rIHdlJ3ZlIG5lZWRlZCB0aGlzIHRlcm0geWV0IGluIGxtYXAuIGdpdmVuIGhv dw0KIHRyaWNreSBhZ3JlZWluZyB0ZXJtaW5vbG9neSBpcywgY2FuIHdlIGRlbGF5IGRlZmluaW5n IHRoaXMgdGVybSB1bnRpbCB3ZSdyZSBzdXJlIHdlIG5lZWQgaXQuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj50aGFua3M8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPnBoaWw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E61130DE6768GAALPA1MSGUSRBF_-- From nobody Thu Jun 5 05:53:03 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 6DD621A008C; Thu, 5 Jun 2014 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 2_RG1BMt4Tz0; Thu, 5 Jun 2014 05:52:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE9D1A00E5; Thu, 5 Jun 2014 05:52:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0B3AE707; Thu, 5 Jun 2014 14:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Gqq2Bnuz-P9c; Thu, 5 Jun 2014 14:52:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jun 2014 14:52:21 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2CCE20017; Thu, 5 Jun 2014 14:52:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7f-6J4wKeXpw; Thu, 5 Jun 2014 14:52:21 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (not verified)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 618FA20013; Thu, 5 Jun 2014 14:52:21 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 14:52:21 +0200 From: "Bajpai, Vaibhav" To: "ippm@ietf.org" Thread-Topic: [draft-ietf-ippm-lmap-path-03]: cgn deployments Thread-Index: AQHPgLz81oXOILZXKkGigR5fFju6tA== Date: Thu, 5 Jun 2014 12:52:20 +0000 Message-ID: <8975D915-4A81-4A86-8FF6-961D9F54EC0B@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [213.157.249.122] Content-Type: multipart/signed; boundary="Apple-Mail=_CD4C77BF-DD38-441C-B75A-65A77C0AE7F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ebkp8IJBqbq1G6Ti8sBoermg20I Cc: "Bajpai, Vaibhav" , "" Subject: [lmap] [draft-ietf-ippm-lmap-path-03]: cgn deployments 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, 05 Jun 2014 12:52:53 -0000 --Apple-Mail=_CD4C77BF-DD38-441C-B75A-65A77C0AE7F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, This is with reference to draft-ietf-ippm-lmap-path-03 [1]. [1] http://tools.ietf.org/html/draft-ietf-ippm-lmap-path-03 Translation Between Reference Path and Various Technologies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subsc. -- Private -- Private -- Service-- Intra IP -- GRA -- Transit device Net #1 Net #2 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|------|-BRAS-|------| |------DSL Network---| |_______Un-managed sub-path________|__Managed sub-path__| The BRAS is deployed at mp150 within the reference path. However, if I = compare this with the specific case of CGN deployments: Subsc. -- Private ------------- Service-- Intra IP -- GRA -- Transit device Net #1 Demarc. Access GW GRA GW mp000 mp100 mp150 mp190 mp200 |--UE--|------------CPE/NAT--------|------|-CGN-|------| |-----DSL Network---| |_______Un-managed sub-path________|_Managed sub-path__| GRA =3D Globally Routable Address, GW =3D Gateway A Carrier Grade NAT (CGN) deployed in the Service Provider's access network would be positioned between mp100 and mp190, and the egress side of the CGN may be designated mp150. mp150 is generally an intermediate measurement point in the same address space as mp190. The CGN is also deployed at mp150 in the ^ figure. Is the CGN embedded = within the BRAS? If not, it would be nice to know if the CGN is deployed before = the BRAS or after the BRAS within the reference path. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com --Apple-Mail=_CD4C77BF-DD38-441C-B75A-65A77C0AE7F4 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 iQEcBAEBCgAGBQJTkGgDAAoJEHR3XKwTWKOZ1R0H/iiWs0yiRP1sNy9TRisyJpwn urZrF6p3w7vMdFlgNYJk5yK9uPVRi6MFraZeG2UB3QQoyf2n9Dhu3RmKZ4OkeKfG D0h0JYsdWeOsDTRrOabyH3+wn5IjAfXkDroIXZNxTSiBJUfn2m3Msl7Bi2QbP9O2 tkHvXQe3vKlLAXpOyTZCxG58m/VXaofUJ74KXouCZZkg1l55M3m1MjN9MhLJr+i9 7o61zh785vXs3GhH0L9Lp5UPk7L7jMGgfWOJuNhIAxJnA8rLmQBpgyxT7Rsw4En/ 2RpW/9JTLFfijfR7KKRQJuxUG9ePIzXZQTPTlWQuID38lqzqqZ1qvAUzjZ/zcbY= =g+Pa -----END PGP SIGNATURE----- --Apple-Mail=_CD4C77BF-DD38-441C-B75A-65A77C0AE7F4-- From nobody Thu Jun 5 08:33:28 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 510DF1A024D for ; Thu, 5 Jun 2014 08:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 NfuhFb2Fo9sG for ; Thu, 5 Jun 2014 08:33:23 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4D51A0193 for ; Thu, 5 Jun 2014 08:33:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELAEKNkFPGmAcV/2dsb2JhbABZgkIjIlJYqloGmCcBgQ0WdIInAQEDEgsQXgEMCRVWJgEEGxqIIAGda4RbsEgXhVWITINjgRUEoSyMIIM4gi8 X-IronPort-AV: E=Sophos; i="4.98,981,1392181200"; d="scan'208,217"; a="59415676" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jun 2014 11:32:56 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Jun 2014 11:14:52 -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; Thu, 5 Jun 2014 17:32:54 +0200 From: "Romascanu, Dan (Dan)" To: "" Thread-Topic: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsg== Date: Thu, 5 Jun 2014 15:32:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@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_9904FB1B0159DA42B0B887B7FA8119CA5C7FE703AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cIWGOs3keUFADK-vr0S2f5HSp4s Subject: [lmap] IETF-90: call for agenda items 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, 05 Jun 2014 15:33:27 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE703AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE703AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE703AZFFEXMB04globa_-- From nobody Thu Jun 5 08:43: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 421D41A01A0 for ; Thu, 5 Jun 2014 08:43:00 -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, HTML_MESSAGE=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 SCHnL7vEd5xK for ; Thu, 5 Jun 2014 08:42:53 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BB81A0239 for ; Thu, 5 Jun 2014 08:42:44 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s55FgW83001440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 10:42:33 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C2A011E0049; Thu, 5 Jun 2014 10:42:27 -0500 (CDT) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 8A9961E0069; Thu, 5 Jun 2014 10:42:27 -0500 (CDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s55FgRlZ023247; Thu, 5 Jun 2014 09:42:27 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s55FgQIB023242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 09:42:26 -0600 (MDT) 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; Thu, 5 Jun 2014 10:42:26 -0500 From: "Bugenhagen, Michael K" To: "'Romascanu, Dan (Dan)'" , "''" , "Cook, Charles" , "'David Sinicrope'" Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQ Date: Thu, 5 Jun 2014 15:42:26 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@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.7] Content-Type: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E85Cpodcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/vRqzVTC7BWaKf_3qNI-9owx1w6I Subject: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 15:43:00 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E85Cpodcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, I'll be at the lmap meeting, and will Ask Charles cook to list the delt= as between the two projects in order for the group to be able to discuss th= em. He's been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: Subject: [lmap] IETF-90: call for agenda items Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E85Cpodcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,=

 

    I&#= 8217;ll be at the lmap meeting, and will Ask Charles cook to list the delta= s between the two projects in order for the group to be able to discuss the= m.

 

He’s been on the= reflector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E85Cpodcwmbxex505ct_-- From nobody Thu Jun 5 08:46: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 9CEB51A00F9 for ; Thu, 5 Jun 2014 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 J3y8BkN2JEZ4 for ; Thu, 5 Jun 2014 08:46:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C961A00C6 for ; Thu, 5 Jun 2014 08:46:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQLABOQkFOHCzIm/2dsb2JhbABZgkIjIlJYqloGmCcBgQ0WdIIlAQEBAQMSCxBcAgEIDQQEAQELHQcyFAkIAQEEARIIGoggAaJBsFAXhVWITDcBgyuBFQSWCYsjjCCDOGyBQw X-IronPort-AV: E=Sophos; i="4.98,981,1392181200"; d="scan'208,217"; a="67623549" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jun 2014 11:46:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 05 Jun 2014 11:44:05 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 17:46:13 +0200 From: "Romascanu, Dan (Dan)" To: "Bugenhagen, Michael K" , "''" , "Cook, Charles" , 'David Sinicrope' Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQAAAVCIA= Date: Thu, 5 Jun 2014 15:46:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE75E@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@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: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE75EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/IIXZL_sQnCO3sxF-H_gZGmaxmB8 Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 15:46:26 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE75EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, Yes - we can include this on the agenda after we make sure that there is en= ough time for the discussion of the chartered items. Thanks and Regards, Dan From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Thursday, June 05, 2014 6:42 PM To: Romascanu, Dan (Dan); ''; Cook, Charles; 'David Sinicrop= e' Subject: BBF gap / alignments RE: IETF-90: call for agenda items Dan, I'll be at the lmap meeting, and will Ask Charles cook to list the delt= as between the two projects in order for the group to be able to discuss th= em. He's been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: > Subject: [lmap] IETF-90: call for agenda items Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE75EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,=

 

Yes – we can inc= lude this on the agenda after we make sure that there is enough time for th= e discussion of the chartered items.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Bugenhag= en, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]
Sent: Thursday, June 05, 2014 6:42 PM
To: Romascanu, Dan (Dan); '<lmap@ietf.org>'; Cook, Charles; 'D= avid Sinicrope'
Subject: BBF gap / alignments RE: IETF-90: call for agenda items

 

Dan,=

 

    I&#= 8217;ll be at the lmap meeting, and will Ask Charles cook to list the delta= s between the two projects in order for the group to be able to discuss the= m.

 

He’s been on the= reflector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE75EAZFFEXMB04globa_-- From nobody Thu Jun 5 09:22: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 63B881A0193 for ; Thu, 5 Jun 2014 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 WDOkAH0c48fe for ; Thu, 5 Jun 2014 09:22:25 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131991A02C4 for ; Thu, 5 Jun 2014 09:22: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 83990935.2b492c22c940.9437319.00-2452.23616645.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 05 Jun 2014 16:22:16 +0000 (UTC) X-MXL-Hash: 53909938364a2f99-d45a5bfde6f0de9f72debe6959a80a413d094b6f 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 63990935.0.9437311.00-2350.23616621.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 05 Jun 2014 16:22:15 +0000 (UTC) X-MXL-Hash: 5390993719ad0d29-0e0cf9aa64def7269fdefd6c8a622c2f67cada36 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 s55GMErr005679; Thu, 5 Jun 2014 12:22:14 -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 s55GM26c005542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 12:22:06 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 5 Jun 2014 16:21:41 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 12:21:40 -0400 From: "STARK, BARBARA H" To: "Romascanu, Dan (Dan)" , "Bugenhagen, Michael K" , "''" , "Cook, Charles" , "'David Sinicrope'" Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQAAAVCIAAAO/vkA== Date: Thu, 5 Jun 2014 16:21:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7FE75E@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE75E@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.70.133.103] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE6919GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=gWpOpc-C3pwA:10 a=ofMgfj31e3cA:10 a=5J7jPVQL82wA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=J_N6KFswAAAA:8 a=9lh1ZRuW_KeknDfi-gEA:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=lZB815dzVvQA:10 a=Pwbduc0PQ3sA:10 a=9oQzzcnL-VIi] X-AnalysisOut: [vCZS:21 a=sSqfnL_Ec_-Nuvdx:21 a=yMhMjlubAAAA:8 a=SSmOFEACA] X-AnalysisOut: [AAA:8 a=0dwX_wBH-uRI2psroP8A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4] X-AnalysisOut: [-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=_CA5wd8yj8S] X-AnalysisOut: [b8atE:21 a=8-xaeozIlxjk3mLu:21 a=EaqihWQQX0GizjoO:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oyk29Ba2Yykwd3HD2CHtQHOK_3E Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 16:22:28 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE6919GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This would also depend on a liaison (from BBF to IETF) coming out of the up= coming (end of June) BBF meeting that would allow someone in IETF to have t= he info needed to create an individual contribution that compares the two e= fforts. Since the comparison would not be a formal output of BBF, it would = be important that this be an individual draft and not considered somehow "o= fficial". Only the liaison would be official. With the draft submission cut= -off date of July 4, it may be challenging to get an individual draft done = in time. Having the BBF liaison sent ASAP after the BBF meeting would be cr= itical. Perhaps the lmap chairs could offer advice on whether it might be p= ossible to upload an incomplete placeholder -00 individual draft in time fo= r July 4, and then an -01 before the IETF meeting? Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 11:46 AM To: Bugenhagen, Michael K; ''; Cook, Charles; 'David Sinicro= pe' Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items Hi Michael, Yes - we can include this on the agenda after we make sure that there is en= ough time for the discussion of the chartered items. Thanks and Regards, Dan From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Thursday, June 05, 2014 6:42 PM To: Romascanu, Dan (Dan); '>'; Cook, Ch= arles; 'David Sinicrope' Subject: BBF gap / alignments RE: IETF-90: call for agenda items Dan, I'll be at the lmap meeting, and will Ask Charles cook to list the delt= as between the two projects in order for the group to be able to discuss th= em. He's been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: > Subject: [lmap] IETF-90: call for agenda items Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_2D09D61DDFA73D4C884805CC7865E61130DE6919GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This would also depend on a liaison (from BBF to IET= F) coming out of the upcoming (end of June) BBF meeting that would allow so= meone in IETF to have the info needed to create an individual contribution = that compares the two efforts. Since the comparison would not be a formal output of BBF, it would be important = that this be an individual draft and not considered somehow “official= ”. Only the liaison would be official. With the draft submission cut-= off date of July 4, it may be challenging to get an individual draft done in time. Having the BBF liaison sent ASAP aft= er the BBF meeting would be critical. Perhaps the lmap chairs could offer a= dvice on whether it might be possible to upload an incomplete placeholder -= 00 individual draft in time for July 4, and then an -01 before the IETF meeting?

Barbara

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 11:46 AM
To: Bugenhagen, Michael K; '<lmap@ietf.org>'; Cook, Charles; '= David Sinicrope'
Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agend= a items

 

Hi Michael,=

 

Yes – we can inc= lude this on the agenda after we make sure that there is enough time for th= e discussion of the chartered items.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Bugenhag= en, Michael K [mail= to:Michael.K.Bugenhagen@centurylink.com]
Sent: Thursday, June 05, 2014 6:42 PM
To: Romascanu, Dan (Dan); '<lmap= @ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: BBF gap / alignments RE: IETF-90: call for agenda items

 

Dan,=

 

    I&#= 8217;ll be at the lmap meeting, and will Ask Charles cook to list the delta= s between the two projects in order for the group to be able to discuss the= m.

 

He’s been on the= reflector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_2D09D61DDFA73D4C884805CC7865E61130DE6919GAALPA1MSGUSRBF_-- From nobody Thu Jun 5 09:25:05 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9BF1A035B for ; Thu, 5 Jun 2014 09:24:53 -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, HTML_MESSAGE=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 225YQsFeEfSe for ; Thu, 5 Jun 2014 09:24:47 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D86F1A0193 for ; Thu, 5 Jun 2014 09:24:47 -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 s55GOXcc012832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 11:24:33 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0D1FC1E0055; Thu, 5 Jun 2014 10:24:33 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id C7D0C1E0071; Thu, 5 Jun 2014 10:24:32 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s55GOWnp008715; Thu, 5 Jun 2014 10:24:32 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s55GOUSZ008685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 10:24:32 -0600 (MDT) 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; Thu, 5 Jun 2014 11:24:31 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "'Romascanu, Dan (Dan)'" , "''" , "Cook, Charles" , "'David Sinicrope'" Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQAAAVCIAAAO/vkAAAdzKw Date: Thu, 5 Jun 2014 16:24:30 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7FE75E@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.ITServices.sbc.com> 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: multipart/alternative; boundary="_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E964podcwmbxex505ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EgWCWIrpKPT19p91IY0BZ74XoVc Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 16:24:54 -0000 --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E964podcwmbxex505ct_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Great point ~! Charles that delta / work progression type list should be targeted for a = liaison in the Denver BBF meeting. Killed 2 birds with one stone. :) From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: Thursday, June 05, 2014 11:22 AM To: Romascanu, Dan (Dan); Bugenhagen, Michael K; ''; Cook, C= harles; 'David Sinicrope' Subject: RE: BBF gap / alignments RE: IETF-90: call for agenda items This would also depend on a liaison (from BBF to IETF) coming out of the up= coming (end of June) BBF meeting that would allow someone in IETF to have t= he info needed to create an individual contribution that compares the two e= fforts. Since the comparison would not be a formal output of BBF, it would = be important that this be an individual draft and not considered somehow "o= fficial". Only the liaison would be official. With the draft submission cut= -off date of July 4, it may be challenging to get an individual draft done = in time. Having the BBF liaison sent ASAP after the BBF meeting would be cr= itical. Perhaps the lmap chairs could offer advice on whether it might be p= ossible to upload an incomplete placeholder -00 individual draft in time fo= r July 4, and then an -01 before the IETF meeting? Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 11:46 AM To: Bugenhagen, Michael K; '>'; Cook, C= harles; 'David Sinicrope' Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items Hi Michael, Yes - we can include this on the agenda after we make sure that there is en= ough time for the discussion of the chartered items. Thanks and Regards, Dan From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Thursday, June 05, 2014 6:42 PM To: Romascanu, Dan (Dan); '>'; Cook, Ch= arles; 'David Sinicrope' Subject: BBF gap / alignments RE: IETF-90: call for agenda items Dan, I'll be at the lmap meeting, and will Ask Charles cook to list the delt= as between the two projects in order for the group to be able to discuss th= em. He's been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: > Subject: [lmap] IETF-90: call for agenda items Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E964podcwmbxex505ct_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Great point ~!

 

Charles that  del= ta / work progression type list should be targeted for a  liaison in t= he Denver BBF meeting.

 

Killed 2 birds with on= e stone.

 

= J

 

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: Thursday, June 05, 2014 11:22 AM
To: Romascanu, Dan (Dan); Bugenhagen, Michael K; '<lmap@ietf.org&= gt;'; Cook, Charles; 'David Sinicrope'
Subject: RE: BBF gap / alignments RE: IETF-90: call for agenda items=

 

This would also depend on a liaison (from BBF to IET= F) coming out of the upcoming (end of June) BBF meeting that would allow so= meone in IETF to have the info needed to create an individual contribution = that compares the two efforts. Since the comparison would not be a formal output of BBF, it would be important = that this be an individual draft and not considered somehow “official= ”. Only the liaison would be official. With the draft submission cut-= off date of July 4, it may be challenging to get an individual draft done in time. Having the BBF liaison sent ASAP aft= er the BBF meeting would be critical. Perhaps the lmap chairs could offer a= dvice on whether it might be possible to upload an incomplete placeholder -= 00 individual draft in time for July 4, and then an -01 before the IETF meeting?

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 11:46 AM
To: Bugenhagen, Michael K; '<lma= p@ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agend= a items

 

Hi Michael,=

 

Yes – we can inc= lude this on the agenda after we make sure that there is enough time for th= e discussion of the chartered items.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Bugenhag= en, Michael K [mail= to:Michael.K.Bugenhagen@centurylink.com]
Sent: Thursday, June 05, 2014 6:42 PM
To: Romascanu, Dan (Dan); '<lmap= @ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: BBF gap / alignments RE: IETF-90: call for agenda items

 

Dan,=

 

    I&#= 8217;ll be at the lmap meeting, and will Ask Charles cook to list the delta= s between the two projects in order for the group to be able to discuss the= m.

 

He’s been on the= reflector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_A68F3CAC468B2E48BB775ACE2DD99B5E04B5E964podcwmbxex505ct_-- From nobody Thu Jun 5 09:26: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 761951A0193 for ; Thu, 5 Jun 2014 09:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 ADkvXbAfyoCt for ; Thu, 5 Jun 2014 09:26:37 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5674C1A00A6 for ; Thu, 5 Jun 2014 09:26:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhULAPmYkFPGmAcV/2dsb2JhbABZgkIjIlJYqlsGmCcBgQ0WdIIlAQEBAQMSCxBMEAIBCA0EBAEBCx0HMhQJCAEBBAENBQgaiCABolSwUReFVYhMMQYBBoMlgRUElgmLI4wggzhsgUM X-IronPort-AV: E=Sophos; i="4.98,981,1392181200"; d="scan'208,217"; a="69217696" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Jun 2014 12:26:29 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 05 Jun 2014 12:08:25 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 18:26:27 +0200 From: "Romascanu, Dan (Dan)" To: "STARK, BARBARA H" , "Bugenhagen, Michael K" , "''" , "Cook, Charles" , 'David Sinicrope' Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQAAAVCIAAAO/vkAAAeOMQ Date: Thu, 5 Jun 2014 16:26:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE84B@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C7FE703@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C7FE75E@AZ-FFEXMB04.global.avaya.com> <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE84BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/YnYkzOZTSFpPpPA_udqqzoT1cuE Cc: Benoit Claise Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 16:26:41 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE84BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara, Submitting an initial I-D by 7/4 and a more complete one on Monday 7/21 whe= n the submission gate opens again is OK. Actually the area director (copyin= g Benoit) can provide a special approval for publication at any time. Having a liaison message from the BBF will certainly also help, especially = if it explicitly asks for an answer. Regards, Dan From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Thursday, June 05, 2014 7:22 PM To: Romascanu, Dan (Dan); Bugenhagen, Michael K; ''; Cook, C= harles; 'David Sinicrope' Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items This would also depend on a liaison (from BBF to IETF) coming out of the up= coming (end of June) BBF meeting that would allow someone in IETF to have t= he info needed to create an individual contribution that compares the two e= fforts. Since the comparison would not be a formal output of BBF, it would = be important that this be an individual draft and not considered somehow "o= fficial". Only the liaison would be official. With the draft submission cut= -off date of July 4, it may be challenging to get an individual draft done = in time. Having the BBF liaison sent ASAP after the BBF meeting would be cr= itical. Perhaps the lmap chairs could offer advice on whether it might be p= ossible to upload an incomplete placeholder -00 individual draft in time fo= r July 4, and then an -01 before the IETF meeting? Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 11:46 AM To: Bugenhagen, Michael K; '>'; Cook, C= harles; 'David Sinicrope' Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items Hi Michael, Yes - we can include this on the agenda after we make sure that there is en= ough time for the discussion of the chartered items. Thanks and Regards, Dan From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Thursday, June 05, 2014 6:42 PM To: Romascanu, Dan (Dan); '>'; Cook, Ch= arles; 'David Sinicrope' Subject: BBF gap / alignments RE: IETF-90: call for agenda items Dan, I'll be at the lmap meeting, and will Ask Charles cook to list the delt= as between the two projects in order for the group to be able to discuss th= em. He's been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: > Subject: [lmap] IETF-90: call for agenda items Hi, It's time to build the agenda for the meeting at IETF-90. Please send your = requests including the topic, requested time, and relevant Internet-Draft(s= ). Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE84BAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Barbara,=

 

Submitting an initial = I-D by 7/4 and a more complete one on Monday 7/21 when the submission gate = opens again is OK. Actually the area director (copying Benoit) can provide = a special approval for publication at any time.

 

Having a liaison messa= ge from the BBF will certainly also help, especially if it explicitly asks = for an answer.

 

Regards,

 

Dan<= /p>

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: Thursday, June 05, 2014 7:22 PM
To: Romascanu, Dan (Dan); Bugenhagen, Michael K; '<lmap@ietf.org&= gt;'; Cook, Charles; 'David Sinicrope'
Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agend= a items

 

This would also depend on a liaison (from BBF to IET= F) coming out of the upcoming (end of June) BBF meeting that would allow so= meone in IETF to have the info needed to create an individual contribution = that compares the two efforts. Since the comparison would not be a formal output of BBF, it would be important = that this be an individual draft and not considered somehow “official= ”. Only the liaison would be official. With the draft submission cut-= off date of July 4, it may be challenging to get an individual draft done in time. Having the BBF liaison sent ASAP aft= er the BBF meeting would be critical. Perhaps the lmap chairs could offer a= dvice on whether it might be possible to upload an incomplete placeholder -= 00 individual draft in time for July 4, and then an -01 before the IETF meeting?

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 11:46 AM
To: Bugenhagen, Michael K; '<lma= p@ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agend= a items

 

Hi Michael,=

 

Yes – we can inc= lude this on the agenda after we make sure that there is enough time for th= e discussion of the chartered items.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Bugenhag= en, Michael K [mail= to:Michael.K.Bugenhagen@centurylink.com]
Sent: Thursday, June 05, 2014 6:42 PM
To: Romascanu, Dan (Dan); '<lmap= @ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: BBF gap / alignments RE: IETF-90: call for agenda items

 

Dan,=

 

    I&#= 8217;ll be at the lmap meeting, and will Ask Charles cook to list the delta= s between the two projects in order for the group to be able to discuss the= m.

 

He’s been on the= reflector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It’s time to build the agenda for the meeting = at IETF-90. Please send your requests including the topic, requested time, = and relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C7FE84BAZFFEXMB04globa_-- From nobody Thu Jun 5 09:59: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 7FA0F1A017F for ; Thu, 5 Jun 2014 09:59:54 -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, 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 JNmlI44CdFGu for ; Thu, 5 Jun 2014 09:59:52 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B372A1A0171 for ; Thu, 5 Jun 2014 09:59:51 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-98-5390517e954f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C5.25.27529.E7150935; Thu, 5 Jun 2014 13:16:14 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 12:59:42 -0400 From: David Sinicrope To: "STARK, BARBARA H" , "Romascanu, Dan (Dan)" , "Bugenhagen, Michael K" , "''" , "Cook, Charles" Thread-Topic: BBF gap / alignments RE: IETF-90: call for agenda items Thread-Index: Ac+A02rKmJ4XCnH9S9SitzvojFQnsgAASIKQAAAVCIAAAO/vkAABsnSA Date: Thu, 5 Jun 2014 16:59:42 +0000 Message-ID: In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6919@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_CFB619E3136F02davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonVrcucEKwweF3KhaT/v5ktHj+K9ji 688frBbN57Utrv7pZnRg9XjZP4fR4+DKOeweW+ereCxZ8pMpgCWKyyYlNSezLLVI3y6BK6Nn 9wW2gqb0isU7frI1MHZFdTFyckgImEhsau5ggrDFJC7cW8/WxcjFISRwlFHi2rct7BDOMkaJ Wb//s4NUsQF1rNu4hwUkISLwgVFiyoKHbCAJYQEXiQlnXzCC2CICrhKXb38FsjmAbDeJr1/B SlgEVCRW7r7MAmLzClhJXF64BSzOKRAlse/Hd7ArGIGu+H5qDZjNLCAucevJfKjrBCSW7DnP DGGLSrx8/I8VxBYV0JNY374bqkZJYtLSc6wQvfESPz/3M0LsEpQ4OfMJywRGkVlIxs5CUjYL SRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hIn1nazIqtZwMixipGjtDi1LDfdyGATIzAG j0mw6e5g3PPS8hCjAAejEg/vAvsJwUKsiWXFlbmHGKU5WJTEebVvVgULCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYFQs/35ff8W3X0JnfjPOVzp8bo/h69eL+Zx93i2UPjh938vnIat2/lZ/ /cTcfIXrkQ0vvhgdKr7IPK/88hEmzjxbVqfGm78Ls/SsWco8C31WyMSvrZWXFv3N2X/5YcDc K/V7kmp043Uld7J9PHZ04S8er6ZT4f+nhapHH151vfWvWrp6Vo6C9EQlluKMREMt5qLiRAD4 OqhyogIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/fIjsHpJG0P69itduCOvlK_6bAPQ Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items 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, 05 Jun 2014 16:59:54 -0000 --_000_CFB619E3136F02davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This would=85 what Barbara said. Thanks! Dave From: , BARBARA STARK > Date: Thursday, June 5, 2014 at 12:21 PM To: "Romascanu, Dan (Dan)" >,= Michael Bugenhagen >, "lmap@ietf.org" >, Charles Cook >, David A Sinicrope > Subject: RE: BBF gap / alignments RE: IETF-90: call for agenda items This would also depend on a liaison (from BBF to IETF) coming out of the up= coming (end of June) BBF meeting that would allow someone in IETF to have t= he info needed to create an individual contribution that compares the two e= fforts. Since the comparison would not be a formal output of BBF, it would = be important that this be an individual draft and not considered somehow = =93official=94. Only the liaison would be official. With the draft submissi= on cut-off date of July 4, it may be challenging to get an individual draft= done in time. Having the BBF liaison sent ASAP after the BBF meeting would= be critical. Perhaps the lmap chairs could offer advice on whether it migh= t be possible to upload an incomplete placeholder -00 individual draft in t= ime for July 4, and then an -01 before the IETF meeting? Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 11:46 AM To: Bugenhagen, Michael K; '>'; Cook, C= harles; 'David Sinicrope' Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agenda items Hi Michael, Yes =96 we can include this on the agenda after we make sure that there is = enough time for the discussion of the chartered items. Thanks and Regards, Dan From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Thursday, June 05, 2014 6:42 PM To: Romascanu, Dan (Dan); '>'; Cook, Ch= arles; 'David Sinicrope' Subject: BBF gap / alignments RE: IETF-90: call for agenda items Dan, I=92ll be at the lmap meeting, and will Ask Charles cook to list the de= ltas between the two projects in order for the group to be able to discuss = them. He=92s been on the reflector so I guess all we need is a time slot ? Thanks, Mike From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, June 05, 2014 10:33 AM To: > Subject: [lmap] IETF-90: call for agenda items Hi, It=92s time to build the agenda for the meeting at IETF-90. Please send you= r requests including the topic, requested time, and relevant Internet-Draft= (s). Thanks and Regards, Dan --_000_CFB619E3136F02davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91C2B8D30C911C43B5FE942779C04198@ericsson.com> Content-Transfer-Encoding: quoted-printable
This would=85 what Barbara said.
Thanks!
Dave

From: <STARK>, BARBARA STARK = <bs7652@att.com>
Date: Thursday, June 5, 2014 at 12:= 21 PM
To: "Romascanu, Dan (Dan)"= ; <dromasca@avaya.com>, Mic= hael Bugenhagen <Michael.K.Bugenhagen@centurylink.com>, "lmap@ietf.org" <lmap@ietf.org>, Charles Cook &= lt;Charles.Cook2@centuryli= nk.com>, David A Sinicrope <david.sinicrope@ericsson.com>
Subject: RE: BBF gap / alignments R= E: IETF-90: call for agenda items

This would also depend on a liaison (from BBF to IET= F) coming out of the upcoming (end of June) BBF meeting that would allow so= meone in IETF to have the info needed to create an individual contribution = that compares the two efforts. Since the comparison would not be a formal output of BBF, it would be important = that this be an individual draft and not considered somehow =93official=94.= Only the liaison would be official. With the draft submission cut-off date= of July 4, it may be challenging to get an individual draft done in time. Having the BBF liaison sent ASAP aft= er the BBF meeting would be critical. Perhaps the lmap chairs could offer a= dvice on whether it might be possible to upload an incomplete placeholder -= 00 individual draft in time for July 4, and then an -01 before the IETF meeting?

Barbara

 

From: lmap [mai= lto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 11:46 AM
To: Bugenhagen, Michael K; '<lma= p@ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: Re: [lmap] BBF gap / alignments RE: IETF-90: call for agend= a items

 

Hi Michael,=

 

Yes =96 we can include= this on the agenda after we make sure that there is enough time for the di= scussion of the chartered items.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]
Sent: Thursday, June 05, 2014 6:42 PM
To: Romascanu, Dan (Dan); '<lmap= @ietf.org>'; Cook, Charles; 'David Sinicrope'
Subject: BBF gap / alignments RE: IETF-90: call for agenda items

 

Dan,=

 

    I= =92ll be at the lmap meeting, and will Ask Charles cook to list the deltas = between the two projects in order for the group to be able to discuss them.=

 

He=92s been on the ref= lector so I guess all we need is a time slot ?

 

Thanks,

Mike=

 

From: lmap [mai= lto:lmap-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, June 05, 2014 10:33 AM
To: <lmap@ietf.org>
Subject: [lmap] IETF-90: call for agenda items

 

Hi,

 

It=92s time to build the agenda for the meeting at I= ETF-90. Please send your requests including the topic, requested time, and = relevant Internet-Draft(s).

 

Thanks and Regards,

 

Dan

 

 --_000_CFB619E3136F02davidsinicropeericssoncom_-- From nobody Thu Jun 5 20:18: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 24E3C1A01C5 for ; Thu, 5 Jun 2014 20:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fhJ29J5EDz9a for ; Thu, 5 Jun 2014 20:18:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFAD1A00D5 for ; Thu, 5 Jun 2014 20:18:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW86590; Fri, 06 Jun 2014 03:18:05 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:17:12 +0100 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:18:03 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 11:17:58 +0800 From: Mach Chen To: "philip.eardley@bt.com" Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt Thread-Index: Ac9+c1IuW/beYBhwTt+OiwOS2H6N3AAfK65AAAAEd0AARwjYiQBJYhCQ Date: Fri, 6 Jun 2014 03:17:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/Q_fdBP6Z_Fe7zdLI-1mF4KQVcZM Cc: "lmap@ietf.org" Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 03:18:15 -0000 Hi Phil, Thanks for your response! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Thursday, June 05, 2014 12:00 AM > To: Mach Chen > Cc: lmap@ietf.org > Subject: RE: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt >=20 > > Passive Measurement Task: A Measurement Task in which a Measurement > > Agent observes existing traffic but does not inject Active Measurement = Traffic. >=20 > Given that there are some existing passive measurement solutions (e.g., Y= .1731, > RFC6374 (direct mode)) that may inject extra traffic to help measuring, I= am not > sure whether "does not inject Active Measurement Traffic" is still one of= the > characteristics of Passive Measurement. IMHO, it's better from the tested= object > point of view (e.g., for a measurement task, whether the tested object is= the > existing traffic or injected traffic) to describe what is Passive and Act= ive > measurement. >=20 > [phil] so i think this means your proposal is that we define: Active - me= asure > injected traffic. Passive =3D measure existing traffic (may or may not i= nject traffic) Yes. > i come back to Al's comment. there are pure passive tests, there are pure= active > ones. there are hybrid ones, which lmap hasn't thought too much about. al= l lmap > cares about is that a test will be defined by a registry; ippm subdivide = this registry > into active and passive, so it's their job to decide which side of the li= ne different > hybrid tests sit. > my opinion is that we shouldn't worry about these hybrid tests. Yes, I agree, and let's leave the job to IPPM. >=20 > [phil] my opinion is that it isn't worth further agonising over the defin= ition of > Passive vs Active. (btw, i disagree with your proposed definitions). > i suggest we should either go with the definitions we've got, or we shoul= d delete > the active/passive definitions and do some small re-write so it isn't nee= ded > (particularly in the privacy section) If we cannot achieve an agreement on the definitions of active/passive (mai= nly for passive) , I'd prefer to the later.=20 Thanks, Mach >=20 > phil From nobody Fri Jun 6 01:12: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 6DDB01A041C for ; Fri, 6 Jun 2014 01:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JkvJ0LvlfA3J for ; Fri, 6 Jun 2014 01:12:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3721A0415 for ; Fri, 6 Jun 2014 01:12:15 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Jun 2014 09:07:52 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 6 Jun 2014 09:11:28 +0100 From: To: Date: Fri, 6 Jun 2014 09:11:28 +0100 Thread-Topic: Proposed changes to draft-ietf-lmap-framework-05.txt Thread-Index: AQHPgV7qMuFqJhIwXkW8UnmOxPk/yw== Message-ID: References: , , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C424EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5hNvq9cEy061zb3iUQe2Jw4vv-4 Subject: [lmap] Proposed changes to draft-ietf-lmap-framework-05.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:12:24 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C424EMV67UKRDdoma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB0byBoaWdobGlnaHQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYmVmb3JlIEkgaW1wbGVtZW50 IHRoZW06LQ0KDQoNCiogYSAic3VwcHJlc3Npb24gZmxhZyINCmEgQm9vbGVhbiB0cnVlL2ZhbHNl IGZsYWcgaXMgYWxsIHRoYXQgaXMgcmVxdWlyZWQg4oCTIHRvIHRoZSBNZWFzdXJlbWVudCBUYXNr IENvbmZpZ3VyYXRpb24gaW5kaWNhdGluZyB3aGV0aGVyIHRoYXQgVGFzayBpcyB0byBiZSBzdXBw cmVzc2VkIGJ5IGRlZmF1bHQgKGluIG90aGVyIHdvcmRzLCBpZiB0aGUgQ29udHJvbGxlciBzZW5k cyBhIHN1cHByZXNzaW9uIG1lc3NhZ2Ugd2l0aG91dCBzcGVjaWZ5aW5nIHBhcnRpY3VsYXIgVGFz a3MgdG8gYmUgc3VwcHJlc3NlZCwgdGhlbiB0aGUgTUEgd291bGQgY2hlY2sgdGhlIEJvb2xlYW4g ZmxhZyBmb3IgZWFjaCBUYXNrKQ0KDQoqIHJlbW92ZSB0aGUgZGVmaW5pdGlvbiBvZiBBY3RpdmUg YW5kIFBhc3NpdmUNCg0KcGxlYXNlIHNob3V0IGlmIHlvdSdyZSB1bmhhcHB5IHdpdGggdGhlc2Ug Y2hhbmdlcw0KDQp0aGFua3MNCnBoaWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IGxtYXAgW2xtYXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBoaWxp cC5lYXJkbGV5QGJ0LmNvbSBbcGhpbGlwLmVhcmRsZXlAYnQuY29tXQ0KU2VudDogMDUgSnVuZSAy MDE0IDEwOjEzDQpUbzogS0VOLktPQGFkdHJhbi5jb207IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQ0K Q2M6IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbG1hcF0gRm9sbG93LXVwIG9uIHJlY2Vu dCBkaXNjdXNzaW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDUudHh0DQoNCmkg dGhpbmsgdGhpcyBpcyBhIHZlcnkgZ29vZCBzdWdnZXN0aW9uLiBpIGFncmVlIHRoaXMgaXMgdGhl IHJpZ2h0IHdheSBvZiBzZXBhcmF0aW5nIHBvbGljeSBhbmQgcHJvdG9jb2wNCg0KYXMgYSBzaWRl IGJlbmVmaXQsIHdlIGNhbiB0aGVuIGRyb3AgdGhlIGFjdGl2ZSB2cyBwYXNzaXZlIGRpc3RpbmN0 aW9uIChhbmQgdGVybWlub2xvZ3kpIChhbmQgZG8gc29tZSBzbGlnaHQgcmVwaHJhc2luZyBpbiB0 aGUgcHJpdmFjeSBzZWN0aW9uLCB3aGljaCBpcyB0aGUgbWFpbiBwbGFjZSB0aGF0IHVzZXMgdGhl IHRlcm1zKQ0KDQp0aGFua3MNCnBoaWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IEtFTiBLTyBbS0VOLktPQGFkdHJhbi5jb21dDQpTZW50OiAwNSBKdW5lIDIwMTQg MDA6MDMNClRvOiBHcmVnIE1pcnNreTsgRWFyZGxleSxQTCxQaGlsaXAsVFVCOCBSDQpDYzogbG1h cEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtsbWFwXSBGb2xsb3ctdXAgb24gcmVjZW50IGRpc2N1 c3Npb24gYWJvdXQgZHJhZnQtaWV0Zi1sbWFwLWZyYW1ld29yay0wNS50eHQNCg0KQXMgSSByZWFk IHRoaXMgZW1haWwgdGhyZWFkIHdoaWNoIGlzIHNpbWlsYXIgdG8gZWFybGllciBvbmVzIGRpc2N1 c3NpbmcgYWN0aXZlIHZzLiBwYXNzaXZlLCBJIGtlZXAgdGhpbmtpbmcgYWJvdXQgdGhlIG9ubHkg cGxhY2UgdGhlIGRpc3RpbmN0aW9uIGlzIGJlaW5nIHVzZWQgaW4gdGhlIGxtYXAgZnJhbWV3b3Jr LCB3aGljaCBpcyBmb3Igc3VwcHJlc3Npb24uIEFuZCwgSSBrZWVwIHRoaW5raW5nIHRoYXQgd2Ug YXJlIGNyZWF0aW5nIGEgZGlzdGluY3Rpb24gdGhlIGRldGFpbHMgb2Ygd2hpY2ggd2UgY2Fubm90 IGFncmVlIG9uLCBhbmQgdGhhdCBkaWZmZXJlbnQgdGVzdCBzeXN0ZW0gb3BlcmF0b3JzICBpbnRl bmQgdG8gdXNlIGluIGRpZmZlcmVudCB3YXlzLiBBbmQgdGhpcyBsZWFkcyBtZSB0byB0aGluayB0 aGF0IHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBwcm92aWRlIHRoZSBhZ3JlZWQgc3VwcHJlc3Np b24gYmVoYXZpb3Igd2hpbGUgYWxsb3dpbmcgdGVzdCBzeXN0ZW0gb3BlcmF0b3JzIHRvIG1vZGlm eSBpdCBhcyB0aGV5IHdpc2guDQoNCkRlZmF1bHQgc3VwcHJlc3Npb24gYmVoYXZpb3IsIGFzIHNw ZWNpZmllZCBpbiBmcmFtZXdvcmstMDU6DQoNCuKAnFN1cHByZXNzaW9uIG1lYW5zIHRoYXQgdGhl IE1BIGRvZXMgbm90IGJlZ2luIGFueSBuZXcNCkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrLiBUaGUg aW1wYWN0IG9uIG90aGVyIE1lYXN1cmVtZW50IFRhc2tzIGlzDQpub3QgZGVmaW5lZCBieSBMTUFQ OyBzaW5jZSB0aGV5IGRvIG5vdCBpbnZvbHZlIHRoZSBNQSBjcmVhdGluZyBhbnkNCkFjdGl2ZSBN ZWFzdXJlbWVudCBUcmFmZmljIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3VwcHJlc3MgdGhlbSwgaG93 ZXZlcg0KaXQgbWF5IGJlIHNpbXBsZXIgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGRvIHNvLuKA nQ0KDQpXZSBoYXZlIGFycml2ZWQgYXQgdGhpcyBwb2ludCBiZWNhdXNlIHN0YWtlaG9sZGVycyBj b3VsZCBub3QgYWdyZWUgb24gaG93IHRvIHRyZWF0IFBhc3NpdmUgVGFza3MuIEFzIGEgcmVzdWx0 LCBzb21lIG9wZXJhdG9ycyBtYXkgc3VwcHJlc3MgUGFzc2l2ZSBUYXNrcyBieSBkZWZhdWx0IGFu ZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVlLCB3aXRoIHZhcmlhdGlvbnMgYmV0d2VlbiB0 aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNpbmNlIHdlIGFyZSBzdGlsbCBkZWJhdGluZyB3 aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4gQWN0aXZlIGFuZCBQYXNzaXZlLCB0aGUgbWF0 dGVyIGlzIG5vdCBzZXR0bGVkLg0KDQpUaGVyZSBpcyBhIGJldHRlciB3YXkuIFNpbXBseSBhZGQg YSBmaWVsZCDigJMgYSBCb29sZWFuIHRydWUvZmFsc2UgZmxhZyBpcyBhbGwgdGhhdCBpcyByZXF1 aXJlZCDigJMgdG8gdGhlIE1lYXN1cmVtZW50IFRhc2sgQ29uZmlndXJhdGlvbiBpbmRpY2F0aW5n IHdoZXRoZXIgdGhhdCBUYXNrIGlzIHRvIGJlIHN1cHByZXNzZWQgYnkgZGVmYXVsdC4gSXQgc2hv cnRjdXRzIHRoZSBBY3RpdmUgUGFzc2l2ZSBhcmd1bWVudHMgKGF0IGxlYXN0LCBpbiBsbWFwKSBh bmQgZ2l2ZXMgb3BlcmF0b3JzIGNvbXBsZXRlIGZyZWVkb20gb3ZlciBkZWZhdWx0IHN1cHByZXNz aW9uIGJlaGF2aW9yLg0KDQpUaGUgZGVzY3JpcHRpb24gb2YgYSBNZWFzdXJlbWVudCBNZXRob2Qg aW4gYSByZWdpc3RyeSBjb3VsZCBjb250YWluIGEgcmVjb21tZW5kZWQgdmFsdWUgZm9yIHRoZSBm bGFnLiBIb3dldmVyLCBvcGVyYXRvcnMgd291bGQgYmUgZnJlZSB0byB1c2UgdGhhdCB2YWx1ZSBv ciBvdmVycmlkZSBpdCBpbiB0aGVpciBkZXBsb3ltZW50cy4NCg0KQ29tbWVudHM/DQoNCktlbg0K DQoNCkZyb206IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBHcmVnIE1pcnNreQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDA0LCAyMDE0IDEwOjQwIEFNDQpU bzogcGhpbGlwLmVhcmRsZXlAYnQuY29tDQpDYzogbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtsbWFwXSBGb2xsb3ctdXAgb24gcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgZHJhZnQtaWV0Zi1s bWFwLWZyYW1ld29yay0wNS50eHQNCg0KSGkgUGhpbCwNCnRoYW5rIHlvdSBmb3IgeW91ciBwcm9t cHQgcmVzcG9uc2UgdG8gbXkgY29tbWVudHMuDQppZiBJIGNvbXBhcmUgY29tbW9uIGludGVycHJl dGF0aW9ucyBvZiAib2JzZXJ2ZSIgYW5kICJjb2xsZWN0IjoNCm9iwrdzZXJ2ZSB2ZXJiIFzJmWIt y4h6yZlydlwNCg0KOiB0byB3YXRjaCBhbmQgc29tZXRpbWVzIGFsc28gbGlzdGVuIHRvIChzb21l b25lIG9yIHNvbWV0aGluZykgY2FyZWZ1bGx5DQoNCjogdG8gc2VlIGFuZCBub3RpY2UgKHNvbWVv bmUgb3Igc29tZXRoaW5nKQ0KOiB0byBtYWtlIGEgY29tbWVudCBhYm91dCBzb21ldGhpbmcgeW91 IG5vdGljZQ0KdnMuDQpjb2zCt2xlY3QgdmVyYiBca8mZLcuIbGVrdFwNCg0KOiB0byBnZXQgKHRo aW5ncykgZnJvbSBkaWZmZXJlbnQgcGxhY2VzIGFuZCBicmluZyB0aGVtIHRvZ2V0aGVyDQoNCjog dG8gZ2V0IChvbmUgb3IgbW9yZSB0aGluZ3MpIGZyb20gYSBwbGFjZQ0KOiB0byBnZXQgKHNpbWls YXIgdGhpbmdzKSBhbmQgYnJpbmcgdGhlbSB0b2dldGhlciBhcyBhIGhvYmJ5DQp0aGUgbGF0dGVy IHNlZW1zIGFzIG1vcmUgc3VpdGFibGUgaW4gY2hhcmFjdGVyaXphdGlvbiBvZiByb2xlIG9mIE1B KHMpIGluIGV4ZWN1dGluZyBQYXNzaXZlIE1lYXN1cmVtZW50IG1ldGhvZHMuDQpSRTogTWVhc3Vy ZW1lbnQgRG9tYWluLiBHaXZlbiBlYXJsaWVyIGRpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb24gdG8g dGFrZSBob2xpc3RpYyBhcHByb2FjaCB0byBNQS9NUCByb2xlLCBJIGJlbGlldmUgd2UgYXJlIGF0 IHRoZSBwb2ludCB3aGVyZSBkaXNjdXNzaW9uIG9mIE1lYXN1cmVtZW50IERvbWFpbidzIGRlZmlu aXRpb24gYW5kIHVzZSBpcyB0aW1lbHkgYW5kIGFwcHJvcHJpYXRlLg0KUmVnYXJkcywNCkdyZWcN Cg0KT24gV2VkLCBKdW4gNCwgMjAxNCBhdCA4OjM0IEFNLCA8cGhpbGlwLmVhcmRsZXlAYnQuY29t PG1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+PiB3cm90ZToNCg0KDQpQcm9wb3NhbDotDQoN CkluIHRoZSBJbnRybywgYWRkIHRvIHRoZSBwYXJhZ3JhcGggYWJvdXQgQWN0aXZlICYgUGFzc2l2 ZSBUYXNrczoNCg0KVGhlcmUgbWF5IGFsc28gYmUgTWVhc3VyZW1lbnQgVGFza3MgdGhhdCBhcmUg aW50ZXJtZWRpYXRlIGJldHdlZW4gUGFzc2l2ZSBhbmQgQWN0aXZlIG9uZXM7IGNvbnNpZGVyYXRp b24gaXMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGUuDQoNCg0KDQpJbiB0ZXJt aW5vbG9neSwgdHdlYWsgdGhlIGRlZmluaXRpb25zOi0NCg0KUGFzc2l2ZSBNZWFzdXJlbWVudCBU YXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2ggYSBNZWFzdXJlbWVudCBBZ2VudCBvYnNl cnZlcyBleGlzdGluZyB0cmFmZmljIGJ1dCBkb2VzIG5vdCBpbmplY3QgQWN0aXZlIE1lYXN1cmVt ZW50IFRyYWZmaWMuDQoNCkdJTT4+IEkgdGhpbmsgdGhhdCAib2JzZXJ2ZXMiIGlzIG5vdCB0aGUg c2FtZSBhcyAiY29sbGVjdCBpbmZvcm1hdGlvbiBvZmYiLiBDYW4gaXQgYmUgIi4uLiBpbiB3aGlj aCBhIE1lYXN1cmVtZW50IEFnZW50IGNvbGxlY3RzIGluZm9ybWF0aW9uIG9mZiBleGlzdGluZyB0 cmFmZmljIC4uLiI/IEkgdGhpbmsgdGhhdCBhIE1lYXN1cmVtZW50IEFnZW50IG1heSBjb29yZGlu YXRlIGl0cyBhY3Rpb25zIGluIHBlcmZvcm1pbmcgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIHdp dGggb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRzL1BlZXJzLiBNb3JlIG9uIGl0IGJlbG93Lg0KDQpb cGhpbF0gSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IGRpZmZlcmVuY2UgeW91J3JlIGdl dHRpbmcgYXQgLSB3aGF0IG1lYW5pbmcgZG8geW91IHdhbnQgdG8gY29udmV5IHdpdGggImNvbGxl Y3QgaW5mb3JtYXRpb24iIHRoYXQgZGlmZmVycyBmcm9tICJvYnNlcnZlcyI/DQoNCg0KDQpBY3Rp dmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3Vy ZW1lbnQgQWdlbnQgc2VuZHMgQWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMgdG8sIG9yIHJlY2Vp dmVzIGl0IGZyb20sIG9uZSBvciBtb3JlIG90aGVyIE1lYXN1cmVtZW50IEFnZW50cyBvciBNZWFz dXJlbWVudCBQZWVycywgYW5kIHBlcmhhcHMgY29vcmRpbmF0ZXMgd2l0aCB0aGVtIHVzaW5nIHBy b3RvY29scyBvdXRzaWRlIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZQ0KDQpHSU0+PiBJcyAi QWN0aXZlIE1lYXN1cmVtZW50IFRyYWZmaWMiIHRoZSBzYW1lIGFzICJUZXN0IFRyYWZmaWMiPyBB bmQgSSdkIGxpa2UgdG8gZGlzY3VzcyBuZXcgTWVhc3VyZW1lbnQgRG9tYWluIG9iamVjdCBkZWZp bmVkIGFzOg0KDQpUaGUgY29tbXVuaXR5IG9mIE1lYXN1cmVtZW50IEFnZW50cyBhbmQgTWVhc3Vy ZW1lbnQgUGVlcnMgdGhhdCBjb29wZXJhdGUgaW4gcGVyZm9ybWluZyBhIE1lYXN1cmVtZW50IFRh c2ssIHdoZXRoZXIgQWN0aXZlIG9yIFBhc3NpdmUsIHByZXNlbnQgYSBNZWFzdXJlbWVudCBEb21h aW4uIENvb3JkaW5hdGlvbiBwcm90b2NvbChzKSB1c2VkIHdpdGhpbiBNZWFzdXJlbWVudCBEb21h aW4gYXJlIG91dHNpZGUgb2YgdGhlIGluaXRpYWwgTE1BUCB3b3JrIHNjb3BlLg0KVGhlbiBpbiBk ZWZpbml0aW9ucyBvZiBBY3RpdmUvUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIGluIHRoZSBMTUFQ IEZyYW1ld29yayB3ZSBjYW4gdXNlIHRoZSBNZWFzdXJlbWVudCBEb21haW4gbGlrZToNClBhc3Np dmUgTWVhc3VyZW1lbnQgVGFzazogQSBNZWFzdXJlbWVudCBUYXNrIGluIHdoaWNoIGEgTWVhc3Vy ZW1lbnQgQWdlbnQgY29sbGVjdHMgaW5mb3JtYXRpb24gb2ZmIGV4aXN0aW5nIHRyYWZmaWMgd2l0 aGluIGl0cyBNZWFzdXJlbWVudCBEb21haW4uDQoNCltwaGlsXSB5ZXMsIEFjdGl2ZSBNZWFzdXJl bWVudCBUcmFmZmljIGlzIHdoYXQgeW91IGNvdWxkIGNhbGwgdGVzdCB0cmFmZmljIFsiQWN0aXZl IE1lYXN1cmVtZW50IFRyYWZmaWM6IHRoZSBwYWNrZXQocykgZ2VuZXJhdGVkIGluIG9yZGVyIHRv IGV4ZWN1dGUgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suIl0NCg0KW3BoaWxdIHJlIG1lYXN1 cmVtZW50IGRvbWFpbiAtIGkgY2FuIHNlZSB0aGlzIG1heSBiZSBhIHVzZWZ1bCBjb25jZXB0LCBi dXQgaSBkb24ndCB0aGluayB3ZSd2ZSBuZWVkZWQgdGhpcyB0ZXJtIHlldCBpbiBsbWFwLiBnaXZl biBob3cgdHJpY2t5IGFncmVlaW5nIHRlcm1pbm9sb2d5IGlzLCBjYW4gd2UgZGVsYXkgZGVmaW5p bmcgdGhpcyB0ZXJtIHVudGlsIHdlJ3JlIHN1cmUgd2UgbmVlZCBpdC4NCg0KdGhhbmtzDQpwaGls DQoNCg== --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C424EMV67UKRDdoma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPHN0eWxlPkBmb250LWZhY2Ugew0K CWZvbnQtZmFtaWx5OiBDYWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRh aG9tYTsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7bWFyZ2luOiAxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjsgfQ0KUC5Nc29Ob3JtYWwgew0KCU1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZ OiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOyBGT05ULVNJWkU6IDEycHQNCn0NCkxJLk1zb05v cm1hbCB7DQoJTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7IEZPTlQtU0laRTogMTJwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJTUFSR0lO OiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IEZP TlQtU0laRTogMTJwdA0KfQ0KSDIgew0KCUZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiOyBNQVJHSU4tTEVGVDogMGluOyBGT05ULVNJWkU6IDE4cHQ7IEZPTlQtV0VJR0hUOiBi b2xkOyBNQVJHSU4tUklHSFQ6IDBpbg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1 cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9s bG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpQ IHsNCglGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgTUFSR0lOLUxFRlQ6 IDBpbjsgRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU4tUklHSFQ6IDBpbg0KfQ0KU1BBTi5IZWFkaW5n MkNoYXIgew0KCUZPTlQtRkFNSUxZOiAiQ2FtYnJpYSIsInNlcmlmIjsgQ09MT1I6ICM0ZjgxYmQ7 IEZPTlQtV0VJR0hUOiBib2xkDQp9DQpTUEFOLkVtYWlsU3R5bGUyMCB7DQoJRk9OVC1GQU1JTFk6 ICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkDQp9DQouTXNvQ2hwRGVmYXVs dCB7DQoJRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1zZXJpZiINCn0NCjwvc3R5bGU+PHN0 eWxlIGlkPSJvd2FUZW1wRWRpdFN0eWxlIj48L3N0eWxlPjxzdHlsZSB0aXRsZT0ib3dhUGFyYVN0 eWxlIj48IS0tUCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCi0t Pjwvc3R5bGU+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRlbnQ9Ik1TSFRNTCA5LjAwLjgx MTIuMTY1NDUiPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIHZsaW5rPSJwdXJwbGUiIGxp bms9ImJsdWUiIG9jc2k9IngiPg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IFRhaG9tYTsgRElS RUNUSU9OOiBsdHI7IENPTE9SOiAjMDAwMDAwOyBGT05ULVNJWkU6IHgtc21hbGwiPg0KPGRpdj5K dXN0IHRvIGhpZ2hsaWdodCB0aGUgcHJvcG9zZWQgY2hhbmdlcyBiZWZvcmUgSSBpbXBsZW1lbnQg dGhlbTotPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9InRhaG9tYSI+PC9mb250PiZuYnNwOzwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJ0YWhvbWEiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0idGFob21hIj4qIGEgJnF1b3Q7c3VwcHJlc3Npb24gZmxhZyZxdW90OyA8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMWY0OTdkIiBzaXplPSIzIiBmYWNlPSJDYWxpYnJp Ij5hIEJvb2xlYW4gdHJ1ZS9mYWxzZSBmbGFnIGlzIGFsbCB0aGF0IGlzIHJlcXVpcmVkIOKAkyB0 byB0aGUgTWVhc3VyZW1lbnQgVGFzayBDb25maWd1cmF0aW9uIGluZGljYXRpbmcgd2hldGhlciB0 aGF0IFRhc2sgaXMgdG8gYmUgc3VwcHJlc3NlZCBieSBkZWZhdWx0IChpbiBvdGhlciB3b3Jkcywg aWYgdGhlIENvbnRyb2xsZXIgc2VuZHMgYSBzdXBwcmVzc2lvbiBtZXNzYWdlDQogd2l0aG91dCBz cGVjaWZ5aW5nIHBhcnRpY3VsYXIgVGFza3MgdG8gYmUgc3VwcHJlc3NlZCwgdGhlbiB0aGUgTUEg d291bGQgY2hlY2sgdGhlIEJvb2xlYW4gZmxhZyBmb3IgZWFjaCBUYXNrKTwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIHNpemU9IjMiIGZhY2U9ImNhbGlicmkiPjwvZm9u dD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIHNpemU9IjMiIGZhY2U9 ImNhbGlicmkiPiogcmVtb3ZlIHRoZSBkZWZpbml0aW9uIG9mIEFjdGl2ZSBhbmQgUGFzc2l2ZTwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIHNpemU9IjMiIGZhY2U9ImNh bGlicmkiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIHNp emU9IjMiIGZhY2U9ImNhbGlicmkiPnBsZWFzZSBzaG91dCBpZiB5b3UncmUgdW5oYXBweSB3aXRo IHRoZXNlIGNoYW5nZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMWY0OTdkIiBz aXplPSIzIiBmYWNlPSJjYWxpYnJpIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGNv bG9yPSIjMWY0OTdkIiBzaXplPSIzIiBmYWNlPSJjYWxpYnJpIj50aGFua3M8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGNvbG9yPSIjMWY0OTdkIiBzaXplPSIzIiBmYWNlPSJjYWxpYnJpIj5waGls PC9mb250PjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9 IjIiIGZhY2U9IlRhaG9tYSI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iRElSRUNU SU9OOiBsdHIiIGlkPSJkaXZScEY2MDkwNDkiPg0KPGhyIHRhYmluZGV4PSItMSI+DQo8Zm9udCBj b2xvcj0iIzAwMDAwMCIgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gbG1hcCBb bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgcGhpbGlwLmVhcmRsZXlAYnQuY29t IFtwaGlsaXAuZWFyZGxleUBidC5jb21dPGJyPg0KPGI+U2VudDo8L2I+IDA1IEp1bmUgMjAxNCAx MDoxMzxicj4NCjxiPlRvOjwvYj4gS0VOLktPQGFkdHJhbi5jb207IGdyZWdpbWlyc2t5QGdtYWls LmNvbTxicj4NCjxiPkNjOjwvYj4gbG1hcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2xtYXBdIEZvbGxvdy11cCBvbiByZWNlbnQgZGlzY3Vzc2lvbiBhYm91dCBkcmFmdC1pZXRm LWxtYXAtZnJhbWV3b3JrLTA1LnR4dDxicj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iRk9OVC1GQU1JTFk6IFRhaG9tYTsgRElSRUNUSU9OOiBs dHI7IENPTE9SOiAjMDAwMDAwOyBGT05ULVNJWkU6IHgtc21hbGwiPg0KPGRpdj5pIHRoaW5rIHRo aXMgaXMgYSB2ZXJ5IGdvb2Qgc3VnZ2VzdGlvbi4gaSBhZ3JlZSB0aGlzIGlzIHRoZSByaWdodCB3 YXkgb2Ygc2VwYXJhdGluZyBwb2xpY3kgYW5kIHByb3RvY29sPC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9InRhaG9tYSI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJ0YWhvbWEi PmFzIGEgc2lkZSBiZW5lZml0LCA8L2ZvbnQ+PGZvbnQgZmFjZT0idGFob21hIj53ZSBjYW4gdGhl biBkcm9wIHRoZSBhY3RpdmUgdnMgcGFzc2l2ZSBkaXN0aW5jdGlvbiAoYW5kIHRlcm1pbm9sb2d5 KSAoYW5kIGRvIHNvbWUgc2xpZ2h0IHJlcGhyYXNpbmcgaW4gdGhlIHByaXZhY3kgc2VjdGlvbiwg d2hpY2ggaXMgdGhlIG1haW4gcGxhY2UgdGhhdCB1c2VzIHRoZSB0ZXJtcyk8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9InRhaG9tYSI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJ0YWhvbWEiPnRoYW5rczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0idGFo b21hIj5waGlsPC9mb250PjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGZvbnQgY29sb3I9IiMwMDAw MDAiIHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iRElSRUNUSU9OOiBsdHIiIGlkPSJkaXZScEY2ODYwNSI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4N Cjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9i PiBLRU4gS08gW0tFTi5LT0BhZHRyYW4uY29tXTxicj4NCjxiPlNlbnQ6PC9iPiAwNSBKdW5lIDIw MTQgMDA6MDM8YnI+DQo8Yj5Ubzo8L2I+IEdyZWcgTWlyc2t5OyBFYXJkbGV5LFBMLFBoaWxpcCxU VUI4IFI8YnI+DQo8Yj5DYzo8L2I+IGxtYXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IFtsbWFwXSBGb2xsb3ctdXAgb24gcmVjZW50IGRpc2N1c3Npb24gYWJvdXQgZHJhZnQtaWV0 Zi1sbWFwLWZyYW1ld29yay0wNS50eHQ8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2Pjwv ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENP TE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkFzIEkgcmVhZCB0aGlzIGVtYWlsIHRocmVh ZCB3aGljaCBpcyBzaW1pbGFyIHRvIGVhcmxpZXIgb25lcyBkaXNjdXNzaW5nIGFjdGl2ZSB2cy4g cGFzc2l2ZSwgSSBrZWVwIHRoaW5raW5nIGFib3V0IHRoZSBvbmx5IHBsYWNlIHRoZSBkaXN0aW5j dGlvbiBpcyBiZWluZw0KIHVzZWQgaW4gdGhlIGxtYXAgZnJhbWV3b3JrLCB3aGljaCBpcyBmb3Ig c3VwcHJlc3Npb24uIEFuZCwgSSBrZWVwIHRoaW5raW5nIHRoYXQgd2UgYXJlIGNyZWF0aW5nIGEg ZGlzdGluY3Rpb24gdGhlIGRldGFpbHMgb2Ygd2hpY2ggd2UgY2Fubm90IGFncmVlIG9uLCBhbmQg dGhhdCBkaWZmZXJlbnQgdGVzdCBzeXN0ZW0gb3BlcmF0b3JzICZuYnNwO2ludGVuZCB0byB1c2Ug aW4gZGlmZmVyZW50IHdheXMuIEFuZCB0aGlzIGxlYWRzIG1lIHRvIHRoaW5rIHRoYXQNCiB0aGVy ZSBpcyBhIGJldHRlciB3YXkgdG8gcHJvdmlkZSB0aGUgYWdyZWVkIHN1cHByZXNzaW9uIGJlaGF2 aW9yIHdoaWxlIGFsbG93aW5nIHRlc3Qgc3lzdGVtIG9wZXJhdG9ycyB0byBtb2RpZnkgaXQgYXMg dGhleSB3aXNoLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U LVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0 OTdkOyBGT05ULVNJWkU6IDExcHQiPkRlZmF1bHQgc3VwcHJlc3Npb24gYmVoYXZpb3IsIGFzIHNw ZWNpZmllZCBpbiBmcmFtZXdvcmstMDU6DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xP UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2Vy aWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij7igJxTdXBwcmVzc2lvbiBtZWFu cyB0aGF0IHRoZSBNQSBkb2VzIG5vdCBiZWdpbiBhbnkgbmV3PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+QWN0aXZlIE1lYXN1cmVtZW50 IFRhc2suIFRoZSBpbXBhY3Qgb24gb3RoZXIgTWVhc3VyZW1lbnQgVGFza3MgaXM8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5ub3QgZGVm aW5lZCBieSBMTUFQOyBzaW5jZSB0aGV5IGRvIG5vdCBpbnZvbHZlIHRoZSBNQSBjcmVhdGluZyBh bnk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAx MXB0Ij5BY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0aGVyZSBpcyBubyBuZWVkIHRvIHN1cHBy ZXNzIHRoZW0sIGhvd2V2ZXI8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3 ZDsgRk9OVC1TSVpFOiAxMXB0Ij5pdCBtYXkgYmUgc2ltcGxlciBmb3IgYW4gaW1wbGVtZW50YXRp b24gdG8gZG8gc28u4oCdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7 IEZPTlQtU0laRTogMTFwdCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+V2UgaGF2ZSBhcnJpdmVkIGF0IHRoaXMgcG9pbnQg YmVjYXVzZSBzdGFrZWhvbGRlcnMgY291bGQgbm90IGFncmVlIG9uIGhvdyB0byB0cmVhdCBQYXNz aXZlIFRhc2tzLiBBcyBhIHJlc3VsdCwgc29tZSBvcGVyYXRvcnMgbWF5IHN1cHByZXNzIFBhc3Np dmUgVGFza3MNCiBieSBkZWZhdWx0IGFuZCBvdGhlcnMgbWF5IGxldCB0aGVtIGNvbnRpbnVlLCB3 aXRoIHZhcmlhdGlvbnMgYmV0d2VlbiB0aG9zZSB0d28gZXh0cmVtZXMuIEFuZCB5ZXQsIHNpbmNl IHdlIGFyZSBzdGlsbCBkZWJhdGluZyB3aGVyZSB0byBkcmF3IHRoZSBsaW5lIGJldHdlZW4gQWN0 aXZlIGFuZCBQYXNzaXZlLCB0aGUgbWF0dGVyIGlzIG5vdCBzZXR0bGVkLjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPlRo ZXJlIGlzIGEgYmV0dGVyIHdheS4gU2ltcGx5IGFkZCBhIGZpZWxkIOKAkyBhIEJvb2xlYW4gdHJ1 ZS9mYWxzZSBmbGFnIGlzIGFsbCB0aGF0IGlzIHJlcXVpcmVkIOKAkyB0byB0aGUgTWVhc3VyZW1l bnQgVGFzayBDb25maWd1cmF0aW9uIGluZGljYXRpbmcgd2hldGhlcg0KIHRoYXQgVGFzayBpcyB0 byBiZSBzdXBwcmVzc2VkIGJ5IGRlZmF1bHQuIEl0IHNob3J0Y3V0cyB0aGUgQWN0aXZlIFBhc3Np dmUgYXJndW1lbnRzIChhdCBsZWFzdCwgaW4gbG1hcCkgYW5kIGdpdmVzIG9wZXJhdG9ycyBjb21w bGV0ZSBmcmVlZG9tIG92ZXIgZGVmYXVsdCBzdXBwcmVzc2lvbiBiZWhhdmlvci48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0 Ij5UaGUgZGVzY3JpcHRpb24gb2YgYSBNZWFzdXJlbWVudCBNZXRob2QgaW4gYSByZWdpc3RyeSBj b3VsZCBjb250YWluIGEgcmVjb21tZW5kZWQgdmFsdWUgZm9yIHRoZSBmbGFnLiBIb3dldmVyLCBv cGVyYXRvcnMgd291bGQgYmUgZnJlZSB0byB1c2UgdGhhdCB2YWx1ZQ0KIG9yIG92ZXJyaWRlIGl0 IGluIHRoZWlyIGRlcGxveW1lbnRzLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAj MWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7 IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkNvbW1lbnRzPzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywn c2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPktl bjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEx cHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U LVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAu NWluIiBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgRk9OVC1TSVpFOiAxMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBw dCI+IGxtYXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkdyZWcgTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAwNCwgMjAx NCAxMDo0MCBBTTxicj4NCjxiPlRvOjwvYj4gcGhpbGlwLmVhcmRsZXlAYnQuY29tPGJyPg0KPGI+ Q2M6PC9iPiBsbWFwQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbG1hcF0gRm9s bG93LXVwIG9uIHJlY2VudCBkaXNjdXNzaW9uIGFib3V0IGRyYWZ0LWlldGYtbG1hcC1mcmFtZXdv cmstMDUudHh0PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFBoaWwsPC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFz cz0iTXNvTm9ybWFsIj50aGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlIHRvIG15IGNv bW1lbnRzLjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9 Ik1zb05vcm1hbCI+aWYgSSBjb21wYXJlIGNvbW1vbiBpbnRlcnByZXRhdGlvbnMgb2YgJnF1b3Q7 b2JzZXJ2ZSZxdW90OyBhbmQgJnF1b3Q7Y29sbGVjdCZxdW90Ozo8L3A+DQo8ZGl2IGlkPSJoZWFk d29yZCI+DQo8aDIgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+PHNwYW4gc3R5bGU9IkZPTlQt V0VJR0hUOiBub3JtYWwiPm9iwrdzZXJ2ZTxlbT4gdmVyYjwvZW0+IFzJmWIty4h6yZlydlw8L3Nw YW4+DQo8L2gyPg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjogdG8gd2F0 Y2ggYW5kIHNvbWV0aW1lcyBhbHNvIGxpc3RlbiB0byAoc29tZW9uZSBvciBzb21ldGhpbmcpIGNh cmVmdWxseTwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjogdG8gc2VlIGFuZCBu b3RpY2UgKHNvbWVvbmUgb3Igc29tZXRoaW5nKTwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDog MC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPjogdG8gbWFrZSBhIGNvbW1lbnQgYWJvdXQgc29tZXRo aW5nIHlvdSBub3RpY2U8L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0i TXNvTm9ybWFsIj52cy48L3A+DQo8aDIgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+PHNwYW4g c3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWwiPmNvbMK3bGVjdDxlbT4gdmVyYjwvZW0+IFxryZkt y4hsZWt0XDwvc3Bhbj4NCjwvaDI+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVp biI+OiB0byBnZXQgKHRoaW5ncykgZnJvbSBkaWZmZXJlbnQgcGxhY2VzIGFuZCBicmluZyB0aGVt IHRvZ2V0aGVyPC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+OiB0byBnZXQgKG9u ZSBvciBtb3JlIHRoaW5ncykgZnJvbSBhIHBsYWNlPC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZU OiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+OiB0byBnZXQgKHNpbWlsYXIgdGhpbmdzKSBhbmQg YnJpbmcgdGhlbSB0b2dldGhlciBhcyBhIGhvYmJ5PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGxh dHRlciBzZWVtcyBhcyBtb3JlIHN1aXRhYmxlIGluIGNoYXJhY3Rlcml6YXRpb24gb2Ygcm9sZSBv ZiBNQShzKSBpbiBleGVjdXRpbmcgUGFzc2l2ZSBNZWFzdXJlbWVudCBtZXRob2RzLjwvcD4NCjwv ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQ7IE1BUkdJTi1MRUZUOiAwLjVpbjsg TUFSR0lOLVJJR0hUOiAwaW4iIGNsYXNzPSJNc29Ob3JtYWwiPg0KUkU6IE1lYXN1cmVtZW50IERv bWFpbi4gR2l2ZW4gZWFybGllciBkaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9uIHRvIHRha2UgaG9s aXN0aWMgYXBwcm9hY2ggdG8gTUEvTVAgcm9sZSwgSSBiZWxpZXZlIHdlIGFyZSBhdCB0aGUgcG9p bnQgd2hlcmUgZGlzY3Vzc2lvbiBvZiBNZWFzdXJlbWVudCBEb21haW4ncyBkZWZpbml0aW9uIGFu ZCB1c2UgaXMgdGltZWx5IGFuZCBhcHByb3ByaWF0ZS48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJN QVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPC9wPg0KPC9kaXY+ DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnPC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQ7IE1BUkdJTi1M RUZUOiAwLjVpbjsgTUFSR0lOLVJJR0hUOiAwaW4iIGNsYXNzPSJNc29Ob3JtYWwiPg0KJm5ic3A7 PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFdlZCwgSnVuIDQsIDIwMTQgYXQgODozNCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsaXAuZWFyZGxleUBidC5jb20iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4i IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPiZuYnNwOzwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogI2NjY2NjYyAxcHQgc29saWQ7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogNnB0OyBQQURESU5HLVJJR0hUOiAwaW47 IE1BUkdJTi1MRUZUOiA0LjhwdDsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IE1BUkdJTi1SSUdI VDogMGluOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogMGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0 eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZP TlQtU0laRTogMTBwdCIgbGFuZz0iRU4tR0IiPlByb3Bvc2FsOi08L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21h Jywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1H QiI+SW4gdGhlIEludHJvLCBhZGQgdG8gdGhlIHBhcmFncmFwaCBhYm91dCBBY3RpdmUgJmFtcDsg UGFzc2l2ZSBUYXNrczo8L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBi bGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1HQiI+VGhlcmUgbWF5IGFsc28gYmUgTWVh c3VyZW1lbnQgVGFza3MgdGhhdCBhcmUgaW50ZXJtZWRpYXRlIGJldHdlZW4gUGFzc2l2ZSBhbmQg QWN0aXZlIG9uZXM7IGNvbnNpZGVyYXRpb24gaXMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdv cmsNCiBzY29wZS48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFj azsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1HQiI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t YScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4t R0IiPkluIHRlcm1pbm9sb2d5LCB0d2VhayB0aGUgZGVmaW5pdGlvbnM6LTwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9 IkVOLUdCIj5QYXNzaXZlIE1lYXN1cmVtZW50IFRhc2s6IEEgTWVhc3VyZW1lbnQgVGFzayBpbiB3 aGljaCBhIE1lYXN1cmVtZW50IEFnZW50IG9ic2VydmVzIGV4aXN0aW5nIHRyYWZmaWMgYnV0IGRv ZXMgbm90IGluamVjdCBBY3RpdmUgTWVhc3VyZW1lbnQNCiBUcmFmZmljLjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9 IkVOLUdCIj5HSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgJnF1b3Q7b2JzZXJ2ZXMmcXVvdDsgaXMg bm90IHRoZSBzYW1lIGFzICZxdW90O2NvbGxlY3QgaW5mb3JtYXRpb24gb2ZmJnF1b3Q7LiBDYW4g aXQgYmUgJnF1b3Q7Li4uIGluIHdoaWNoIGEgTWVhc3VyZW1lbnQgQWdlbnQgY29sbGVjdHMgaW5m b3JtYXRpb24NCiBvZmYgZXhpc3RpbmcgdHJhZmZpYyAuLi4mcXVvdDs/IEkgdGhpbmsgdGhhdCBh IE1lYXN1cmVtZW50IEFnZW50IG1heSBjb29yZGluYXRlIGl0cyBhY3Rpb25zIGluIHBlcmZvcm1p bmcgUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrIHdpdGggb3RoZXIgTWVhc3VyZW1lbnQgQWdlbnRz L1BlZXJzLiBNb3JlIG9uIGl0IGJlbG93Ljwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBz dHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJ WkU6IDEwcHQiIGxhbmc9IkVOLUdCIj48L3NwYW4+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJs YWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IkVOLUdCIj5bcGhpbF0gSSBkb24ndCByZWFsbHkg dW5kZXJzdGFuZCB3aGF0IGRpZmZlcmVuY2UgeW91J3JlIGdldHRpbmcgYXQgLSB3aGF0IG1lYW5p bmcgZG8geW91IHdhbnQgdG8gY29udmV5IHdpdGggJnF1b3Q7Y29sbGVjdA0KIGluZm9ybWF0aW9u JnF1b3Q7IHRoYXQgZGlmZmVycyBmcm9tICZxdW90O29ic2VydmVzJnF1b3Q7Pzwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiI+PHNw YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFj azsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJFTi1HQiI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIHN0 eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t YScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4t R0IiPkFjdGl2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hpY2gg YSBNZWFzdXJlbWVudCBBZ2VudCBzZW5kcyBBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYyB0bywg b3IgcmVjZWl2ZXMgaXQgZnJvbSwgb25lDQogb3IgbW9yZSBvdGhlciBNZWFzdXJlbWVudCBBZ2Vu dHMgb3IgTWVhc3VyZW1lbnQgUGVlcnMsIGFuZCBwZXJoYXBzIGNvb3JkaW5hdGVzIHdpdGggdGhl bSB1c2luZyBwcm90b2NvbHMgb3V0c2lkZSB0aGUgaW5pdGlhbCBMTUFQIHdvcmsgc2NvcGU8L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6 ICNjY2NjY2MgMXB0IHNvbGlkOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDZw dDsgUEFERElORy1SSUdIVDogMGluOyBNQVJHSU4tTEVGVDogNC44cHQ7IEJPUkRFUi1UT1A6IG1l ZGl1bSBub25lOyBNQVJHSU4tUklHSFQ6IDBpbjsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsg UEFERElORy1UT1A6IDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDog MC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBD T0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iRU4tR0IiPkdJTSZndDsmZ3Q7IElz ICZxdW90O0FjdGl2ZSBNZWFzdXJlbWVudCBUcmFmZmljJnF1b3Q7IHRoZSBzYW1lIGFzICZxdW90 O1Rlc3QgVHJhZmZpYyZxdW90Oz8gQW5kIEknZCBsaWtlIHRvIGRpc2N1c3MgbmV3IE1lYXN1cmVt ZW50IERvbWFpbiBvYmplY3QgZGVmaW5lZCBhczombmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6ICNjY2NjY2MgMXB0IHNvbGlkOyBQQURESU5HLUJPVFRP TTogMGluOyBQQURESU5HLUxFRlQ6IDZwdDsgUEFERElORy1SSUdIVDogMGluOyBNQVJHSU4tTEVG VDogNC44cHQ7IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBNQVJHSU4tUklHSFQ6IDBpbjsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFu Zz0iRU4tR0IiPlRoZSBjb21tdW5pdHkgb2YgTWVhc3VyZW1lbnQgQWdlbnRzIGFuZCBNZWFzdXJl bWVudCBQZWVycyB0aGF0IGNvb3BlcmF0ZSBpbiBwZXJmb3JtaW5nIGEgTWVhc3VyZW1lbnQgVGFz aywgd2hldGhlciBBY3RpdmUgb3IgUGFzc2l2ZSwNCiBwcmVzZW50IGEgTWVhc3VyZW1lbnQgRG9t YWluLiBDb29yZGluYXRpb24gcHJvdG9jb2wocykgdXNlZCB3aXRoaW4gTWVhc3VyZW1lbnQgRG9t YWluIGFyZSBvdXRzaWRlIG9mIHRoZSBpbml0aWFsIExNQVAgd29yayBzY29wZS48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lO LUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6 ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPlRo ZW4gaW4gZGVmaW5pdGlvbnMgb2YgQWN0aXZlL1Bhc3NpdmUgTWVhc3VyZW1lbnQgVGFzayBpbiB0 aGUgTE1BUCBGcmFtZXdvcmsgd2UgY2FuIHVzZSB0aGUgTWVhc3VyZW1lbnQgRG9tYWluIGxpa2U6 PGJyPg0KUGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrOiBBIE1lYXN1cmVtZW50IFRhc2sgaW4gd2hp Y2ggYSBNZWFzdXJlbWVudCBBZ2VudCBjb2xsZWN0cyBpbmZvcm1hdGlvbiBvZmYgZXhpc3Rpbmcg dHJhZmZpYyB3aXRoaW4gaXRzIE1lYXN1cmVtZW50IERvbWFpbi48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt c2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPiZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNl cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPltwaGlsXSB5ZXMsIEFjdGl2ZSBN ZWFzdXJlbWVudCBUcmFmZmljIGlzIHdoYXQgeW91IGNvdWxkIGNhbGwgdGVzdCB0cmFmZmljIFsm cXVvdDtBY3RpdmUgTWVhc3VyZW1lbnQgVHJhZmZpYzogdGhlIHBhY2tldChzKSBnZW5lcmF0ZWQN CiBpbiBvcmRlciB0byZuYnNwO2V4ZWN1dGUgYW4gQWN0aXZlIE1lYXN1cmVtZW50IFRhc2suJnF1 b3Q7XTwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4t TEVGVDogMC41aW4iIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9z cGFuPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41 aW4iIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScs J3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+W3BoaWxdIHJlIG1l YXN1cmVtZW50IGRvbWFpbiAtIGkgY2FuIHNlZSB0aGlzIG1heSBiZSBhIHVzZWZ1bCBjb25jZXB0 LCBidXQgaSBkb24ndCB0aGluayB3ZSd2ZSBuZWVkZWQgdGhpcyB0ZXJtIHlldCBpbiBsbWFwLiBn aXZlbg0KIGhvdyB0cmlja3kgYWdyZWVpbmcgdGVybWlub2xvZ3kgaXMsIGNhbiB3ZSBkZWxheSBk ZWZpbmluZyB0aGlzIHRlcm0gdW50aWwgd2UncmUgc3VyZSB3ZSBuZWVkIGl0Ljwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJs YWNrOyBGT05ULVNJWkU6IDEwcHQiPnRoYW5rczwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05U LVNJWkU6IDEwcHQiPnBoaWw8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAwLjVpbiIgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C424EMV67UKRDdoma_-- From nobody Fri Jun 6 06:49: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 65C731A00E5 for ; Fri, 6 Jun 2014 06:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 QfA63Cq_UWCY for ; Fri, 6 Jun 2014 06:49:13 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED5C1A00A5 for ; Fri, 6 Jun 2014 06:49:12 -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) over TLS secured channel with ESMTP id 1d6c1935.0.10034055.00-2290.25078889.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 06 Jun 2014 13:49:06 +0000 (UTC) X-MXL-Hash: 5391c6d22fd23313-0f47b2b3c86b9f16660c2234ef013aa21e5d3c8d 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 s56Dn5Hp032370 for ; Fri, 6 Jun 2014 09:49:05 -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 s56Dn3bU032367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jun 2014 09:49:03 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 6 Jun 2014 13:48:48 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 09:48:48 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEw== Date: Fri, 6 Jun 2014 13:48:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=FFTTgDLji] X-AnalysisOut: [kw9p5rGpfwA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/hnvF51pq2t54fYz8lUK46BTawxQ Subject: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 13:49:14 -0000 Now that it appears we may have resolved the LMAP active/passive debates (b= y getting rid of the words) and ambiguity around "which tasks get suppresse= d by default", maybe we could agree on what Measurement Method and Measurem= ent Task are? I'd like to propose: Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves mul= tiple MAs or MPs, each may perform different roles. Measurement Task: The act that consists of the single operation of a Measurement Method role at a particular time and with all its Input Parameters set to specific values. Measurement Method role is not a defined term, but can be used to express t= he capability implemented within a MA (or MP) that allows it to participate= in a Measurement Method. I see that various ippm RFCs use the word "role" = in this way, including OWAMP and TWAMP. If there is a need to talk about an instance of executing a Measurement Met= hod, this could be called a Measurement Method instance. Again, without def= inition as a formal term. There exist several instances of "Measurement Method" that would need to be= come "Measurement Method role". For example: "A Measurement Task is a specific instantiation of a Measurement Method role." Capabilities: Information about the performance measurement capabilities of the MA, in particular the Measurement Method roles that = it can perform, and the device hosting the MA, for example its interface type and speed, but not dynamic information. "the Measurement Method roles that the MA supports" But most discussion of Measurement Method in framework is of the Measuremen= t Method and not the Measurement Method role.=20 There is one instance where "Measurement Task capability" is used in the sa= me sense as a Measurement Method role: "...Measurement Agents may come from different vendors, be in wired and wireless networks, have different Measurement Task capabilities and be on devices with IPv4 or IPv6 addresses." I found one instance where I question the use of "Measurement Task" and won= der if it should be "Measurement Method": "Some Measurement Tasks involve several MAs acting in a coordinated fashion."=20 In my scan of framework, I couldn't find a place where I thought Measuremen= t Task was used to mean a Measurement Method instance. Barbara From nobody Fri Jun 6 07:51: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 1AD4A1A01CE for ; Fri, 6 Jun 2014 07:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651] 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 6XgF8A3RcMll for ; Fri, 6 Jun 2014 07:51:07 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1F1A019A for ; Fri, 6 Jun 2014 07:51:07 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1EBB1A0AAF for ; Fri, 6 Jun 2014 10:51:00 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id D1CE9A0AAA for ; Fri, 6 Jun 2014 10:50:59 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.233]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 10:50:59 -0400 From: Sharam Hakimi To: "lmap@ietf.org" Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAAc3NA Date: Fri, 6 Jun 2014 14:50:58 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7059377@SPQCMBX01.exfo.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.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-20740.007 X-TM-AS-Result: No--10.841-5.0-31-10 X-imss-scan-details: No--10.841-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20740.007 X-TMASE-Result: 10--10.841000-5.000000 X-TMASE-MatchedRID: byfwvk+IcRk14gRk5bRTwUNTnAhL0/m3IR1rLBJm/M4s7eP5cPCWQyNe QC4GiE4ORLEj0BUXCAs1hgVNDSx/9+yt+a9Mtf+esyw+ZJnFumQhwKIIdklOV617z5MiFvey/rZ zL50JflOCcoOBE3aAcpRawproEh7WojE6+IZVH0kFXjo73ecXmrTEjNWvtSVv2viB/Jr4D1SR28 jE25zLv+CmWEBUnB8lfgG2G1WC9BfBXlkPaxAt1UhEDfw/93BuCt59Uh3p/NU65nD7EBamdnZ0h 2C8VxBOJNPwaGTj6UnZNOKfo2gpqV47muLm2Ts0e0i2wcB24/G9/uha+Ailn3e9QDr8+LTcRYsQ TODhY4xOgByPiHgDXOtvoLxbfO+JeBDuPTgr5SW1PiMh4ZF39UGV2YNiPCWm51ONI4UL++qjxYy RBa/qJcaUO+wtQNbajoczmuoPCq3q1DyTOeF+5C2w33DVAwwVDu5sUUziXtTRkJJ8t2Fj5SmXe1 F9yrjE Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9ya4k6HEUCItLnC-IDtJGc72zPY Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 14:51:09 -0000 Barbara, I understand the intention but I do not think adding another definition wil= l help in this case. Also a measurement task can be a single or a sequence = of methods to achieve a single result(even though we have not defied a sequ= ence yet).=20 Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, June 06, 2014 9:49 AM To: lmap@ietf.org Subject: [lmap] Measurement Methods and Tasks Now that it appears we may have resolved the LMAP active/passive debates (b= y getting rid of the words) and ambiguity around "which tasks get suppresse= d by default", maybe we could agree on what Measurement Method and Measurem= ent Task are? I'd like to propose: Measurement Method: The process for assessing the value of a Metric; the process of measuring some performance or reliability parameter associated with the transfer of traffic; where this process involves mul= tiple MAs or MPs, each may perform different roles. Measurement Task: The act that consists of the single operation of a Measurement Method role at a particular time and with all its Input Parameters set to specific values. Measurement Method role is not a defined term, but can be used to express t= he capability implemented within a MA (or MP) that allows it to participate= in a Measurement Method. I see that various ippm RFCs use the word "role" = in this way, including OWAMP and TWAMP. If there is a need to talk about an instance of executing a Measurement Met= hod, this could be called a Measurement Method instance. Again, without def= inition as a formal term. There exist several instances of "Measurement Method" that would need to be= come "Measurement Method role". For example: "A Measurement Task is a specific instantiation of a Measurement Method role." Capabilities: Information about the performance measurement capabilities of the MA, in particular the Measurement Method roles that = it can perform, and the device hosting the MA, for example its interface type and speed, but not dynamic information. "the Measurement Method roles that the MA supports" But most discussion of Measurement Method in framework is of the Measuremen= t Method and not the Measurement Method role.=20 There is one instance where "Measurement Task capability" is used in the sa= me sense as a Measurement Method role: "...Measurement Agents may come from different vendors, be in wired and wireless networks, have different Measurement Task capabilities and be on devices with IPv4 or IPv6 addresses." I found one instance where I question the use of "Measurement Task" and won= der if it should be "Measurement Method": "Some Measurement Tasks involve several MAs acting in a coordinated fashion."=20 In my scan of framework, I couldn't find a place where I thought Measuremen= t Task was used to mean a Measurement Method instance. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jun 6 07:55: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 A96C71A049E for ; Fri, 6 Jun 2014 07:55:37 -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 iRrXg6nSBkTk for ; Fri, 6 Jun 2014 07:55:35 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061BD1A04A9 for ; Fri, 6 Jun 2014 07:54:43 -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 s56EsXSP013742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 08:54:34 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BE92E1E0060; Fri, 6 Jun 2014 09:54:28 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 93C711E0049; Fri, 6 Jun 2014 09:54:28 -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 s56EsSus027021; Fri, 6 Jun 2014 08:54:28 -0600 (MDT) Received: from [10.183.199.129] (x1069818.dhcp.intranet [10.183.199.129]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s56EsRef026998; Fri, 6 Jun 2014 08:54:27 -0600 (MDT) Message-ID: <5391D622.8060307@centurylink.com> Date: Fri, 06 Jun 2014 08:54:26 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Enigmail-Version: 1.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/QFvl1-wPpgK6SV_g2GAmFgpdnzc Subject: Re: [lmap] Measurement Methods and Tasks 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: Fri, 06 Jun 2014 14:55:37 -0000 I agree with Barbara that we need to ensure that we have a clear distinction between Measurement Method and Measurement Task. My view of the Measurement Method is that the Measurement Method is what is included in a Registry somewhere. The Measurement Method is essentially a template of a particular type of measurement with a set of parameters that can be specified. A Measurement Task is an instance of the Measurement Method where specific values have been specified for each of the parameters in the Measurement Method. Those that are closer to defining what a Measurement Method is and what a Measurement Task is can hopefully confirm or clarify as appropriate. An MA will need to be able to report to the Controller that it is registered to what capabilities it has relative to what Measurement Methods it can support. If a MA indicates it can support a particular Measurement Method, that implies the MA can support the full range of values that can be assigned by the Controller to the parameters of the Measurement Method in the creation of a Measurement Task. If the MA cannot support the full range of values, then the MA cannot claim to support the Measurement Method. Even though it may not be within the scope of LMAP, I believe it would be helpful if someone can propose a sample Measurement Method with all its parameters as an example that we can use to validate whether the LMAP framework is adequately complete. Maybe a sample Measurement Method can be derived from work in ippm (I have not participated in ippm so I don't know if this can be done). A sample Measurement Method to exercise the LMAP framework should help us to: - determine whether all the bases have been covered in terms of what functions the LMAP framework needs to support to ensure the execution of meaningful Measurement Tasks, and - ensure that a Measurement Method is sufficiently specified to enable results from multiple executions of a Measurement Task generated from the Measurement Method to be compared and analyzed in post processing in a meaningful way. Charles On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > Now that it appears we may have resolved the LMAP active/passive debates (by getting rid of the words) and ambiguity around "which tasks get suppressed by default", maybe we could agree on what Measurement Method and Measurement Task are? > > I'd like to propose: > Measurement Method: The process for assessing the value of a Metric; > the process of measuring some performance or reliability parameter > associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles. > > Measurement Task: The act that consists of the single operation of > a Measurement Method role at a particular time and with all its Input > Parameters set to specific values. > > Measurement Method role is not a defined term, but can be used to express the capability implemented within a MA (or MP) that allows it to participate in a Measurement Method. I see that various ippm RFCs use the word "role" in this way, including OWAMP and TWAMP. > > If there is a need to talk about an instance of executing a Measurement Method, this could be called a Measurement Method instance. Again, without definition as a formal term. > > There exist several instances of "Measurement Method" that would need to become "Measurement Method role". For example: > "A Measurement Task is a specific instantiation of a Measurement > Method role." > > Capabilities: Information about the performance measurement > capabilities of the MA, in particular the Measurement Method roles that it > can perform, and the device hosting the MA, for example its interface > type and speed, but not dynamic information. > > "the Measurement Method roles that the MA supports" > > But most discussion of Measurement Method in framework is of the Measurement Method and not the Measurement Method role. > > There is one instance where "Measurement Task capability" is used in the same sense as a Measurement Method role: "...Measurement Agents may come from > different vendors, be in wired and wireless networks, have > different Measurement Task capabilities and be on devices with > IPv4 or IPv6 addresses." > > I found one instance where I question the use of "Measurement Task" and wonder if it should be "Measurement Method": > "Some Measurement Tasks involve several MAs acting in a coordinated > fashion." > > In my scan of framework, I couldn't find a place where I thought Measurement Task was used to mean a Measurement Method instance. > Barbara > > _______________________________________________ > 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 Fri Jun 6 08:34: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 C9A611A01CC for ; Fri, 6 Jun 2014 08:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 RYpNq-utgWDl for ; Fri, 6 Jun 2014 08:34:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5C71A0205 for ; Fri, 6 Jun 2014 08:34:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 90C53115F; Fri, 6 Jun 2014 17:34:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NrvFQ6k8tbwy; Fri, 6 Jun 2014 17:33:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Jun 2014 17:34:10 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DC542002C; Fri, 6 Jun 2014 17:34:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oRWY0F5u7SWq; Fri, 6 Jun 2014 17:34:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B11EB20013; Fri, 6 Jun 2014 17:34:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7C41F2D53691; Fri, 6 Jun 2014 17:34:09 +0200 (CEST) Date: Fri, 6 Jun 2014 17:34:09 +0200 From: Juergen Schoenwaelder To: "STARK, BARBARA H" Message-ID: <20140606153409.GA15246@elstar.local> Mail-Followup-To: "STARK, BARBARA H" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/1SAfW9YsRodUz3gR7ydZcnacnFw Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:34:32 -0000 I vote for not using 'Measurement Method' anywhere in the LMAP documents. If there is concensus this can't be done, then I think Barabara's proposal is a start but not good enough for a definition. In particular, I find the definition of 'Measurement Task' rather unclear (what is a 'single operation or a .. role'? - this does not help me understand what LMAP measurement tasks (as they are used in the information model) really are. But as said above, my preference is to leave 'Measurement Method' reserved for IPPM folks. ;-) /js On Fri, Jun 06, 2014 at 01:48:47PM +0000, STARK, BARBARA H wrote: > Now that it appears we may have resolved the LMAP active/passive debates (by getting rid of the words) and ambiguity around "which tasks get suppressed by default", maybe we could agree on what Measurement Method and Measurement Task are? > > I'd like to propose: > Measurement Method: The process for assessing the value of a Metric; > the process of measuring some performance or reliability parameter > associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles. > > Measurement Task: The act that consists of the single operation of > a Measurement Method role at a particular time and with all its Input > Parameters set to specific values. > > Measurement Method role is not a defined term, but can be used to express the capability implemented within a MA (or MP) that allows it to participate in a Measurement Method. I see that various ippm RFCs use the word "role" in this way, including OWAMP and TWAMP. > > If there is a need to talk about an instance of executing a Measurement Method, this could be called a Measurement Method instance. Again, without definition as a formal term. > > There exist several instances of "Measurement Method" that would need to become "Measurement Method role". For example: > "A Measurement Task is a specific instantiation of a Measurement > Method role." > > Capabilities: Information about the performance measurement > capabilities of the MA, in particular the Measurement Method roles that it > can perform, and the device hosting the MA, for example its interface > type and speed, but not dynamic information. > > "the Measurement Method roles that the MA supports" > > But most discussion of Measurement Method in framework is of the Measurement Method and not the Measurement Method role. > > There is one instance where "Measurement Task capability" is used in the same sense as a Measurement Method role: "...Measurement Agents may come from > different vendors, be in wired and wireless networks, have > different Measurement Task capabilities and be on devices with > IPv4 or IPv6 addresses." > > I found one instance where I question the use of "Measurement Task" and wonder if it should be "Measurement Method": > "Some Measurement Tasks involve several MAs acting in a coordinated > fashion." > > In my scan of framework, I couldn't find a place where I thought Measurement Task was used to mean a Measurement Method instance. > Barbara > > _______________________________________________ > 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 Fri Jun 6 09:53: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 AB1351A01CB for ; Fri, 6 Jun 2014 09:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 KuHFvv4FIMG7 for ; Fri, 6 Jun 2014 09:53:11 -0700 (PDT) Received: from p02c11o144.mxlogic.net (p02c11o144.mxlogic.net [208.65.144.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C45E1A01B3 for ; Fri, 6 Jun 2014 09:53:11 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 1f1f1935.2b59af61e940.32998.00-531.91135.p02c11o144.mxlogic.net (envelope-from ); Fri, 06 Jun 2014 10:53:05 -0600 (MDT) X-MXL-Hash: 5391f1f121006ec1-17602f9d41c337a35b06f1f8d9ebe8ba9ea39ec0 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o144.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id ec1f1935.0.32625.00-146.90134.p02c11o144.mxlogic.net (envelope-from ); Fri, 06 Jun 2014 10:52:42 -0600 (MDT) X-MXL-Hash: 5391f1da1dabce4f-9132e94d30d99ec63b162ac274b974c703fb76c0 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 11:52:30 -0500 From: KEN KO To: Juergen Schoenwaelder , "STARK, BARBARA H" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAOKbmAAAgLyXA= Date: Fri, 6 Jun 2014 16:52:29 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> In-Reply-To: <20140606153409.GA15246@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=bMKYIZOZ c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=NrtVQHS-r20QujXrR5M] X-AnalysisOut: [A:9 a=40CNvSDrQak6XMW8:21 a=sqrOg-p1WmaxKQCZ:21 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060607); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/C_YSrwUKcaPItHih8K1sNfR9SSU Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 16:53:13 -0000 I support Barbara's proposal. IMO, if we define a Measurement Task as what = is configured and executed by an MA - that is, dependent upon not only Meas= urement Method but the MA's role in implementing that Method - the language= throughout the framework and information model documents becomes more cons= istent and unambiguous. Otherwise, a Measurement Task and a Measurement Tas= k Configuration have different scopes and that seems confusing. With regard to Juergen's preference that references to Measurement Method b= e deleted from the framework, I can't go that far. I think Measurement Meth= ods as a concept are specified in many RFCs and (hopefully soon to be) refe= renced via registry entries, and that the framework should acknowledge this= . Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Friday, June 06, 2014 11:34 AM To: STARK, BARBARA H Cc: lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks I vote for not using 'Measurement Method' anywhere in the LMAP documents. I= f there is concensus this can't be done, then I think Barabara's proposal i= s a start but not good enough for a definition. In particular, I find the definition of 'Measurement Task' rather unclear (= what is a 'single operation or a .. role'? - this does not help me understa= nd what LMAP measurement tasks (as they are used in the information model) = really are. But as said above, my preference is to leave 'Measurement Method' reserved for IPPM folks. ;-) /js On Fri, Jun 06, 2014 at 01:48:47PM +0000, STARK, BARBARA H wrote: > Now that it appears we may have resolved the LMAP active/passive debates = (by getting rid of the words) and ambiguity around "which tasks get suppres= sed by default", maybe we could agree on what Measurement Method and Measur= ement Task are? >=20 > I'd like to propose: > Measurement Method: The process for assessing the value of a Metric; > the process of measuring some performance or reliability parameter > associated with the transfer of traffic; where this process involves m= ultiple MAs or MPs, each may perform different roles. >=20 > Measurement Task: The act that consists of the single operation of > a Measurement Method role at a particular time and with all its Input > Parameters set to specific values. >=20 > Measurement Method role is not a defined term, but can be used to express= the capability implemented within a MA (or MP) that allows it to participa= te in a Measurement Method. I see that various ippm RFCs use the word "role= " in this way, including OWAMP and TWAMP. >=20 > If there is a need to talk about an instance of executing a Measurement M= ethod, this could be called a Measurement Method instance. Again, without d= efinition as a formal term. >=20 > There exist several instances of "Measurement Method" that would need to = become "Measurement Method role". For example: > "A Measurement Task is a specific instantiation of a Measurement > Method role." >=20 > Capabilities: Information about the performance measurement > capabilities of the MA, in particular the Measurement Method roles tha= t it > can perform, and the device hosting the MA, for example its interface > type and speed, but not dynamic information. >=20 > "the Measurement Method roles that the MA supports" >=20 > But most discussion of Measurement Method in framework is of the Measurem= ent Method and not the Measurement Method role.=20 >=20 > There is one instance where "Measurement Task capability" is used in the = same sense as a Measurement Method role: "...Measurement Agents may come fr= om > different vendors, be in wired and wireless networks, have > different Measurement Task capabilities and be on devices with > IPv4 or IPv6 addresses." >=20 > I found one instance where I question the use of "Measurement Task" and w= onder if it should be "Measurement Method": > "Some Measurement Tasks involve several MAs acting in a coordinated > fashion."=20 >=20 > In my scan of framework, I couldn't find a place where I thought Measurem= ent Task was used to mean a Measurement Method instance. > Barbara >=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 Fri Jun 6 09:56: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 1D4341A0170 for ; Fri, 6 Jun 2014 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 pJNW5Dh47j_R for ; Fri, 6 Jun 2014 09:56:22 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B1D1A00F9 for ; Fri, 6 Jun 2014 09:56:21 -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 fa2f1935.2b4940c4d940.10167526.00-2415.25401641.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 06 Jun 2014 16:56:15 +0000 (UTC) X-MXL-Hash: 5391f2af152b1e4e-434a14d121f085ac02def3bec99a2d51bf98c20b 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 3a2f1935.0.10167411.00-2382.25401373.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 06 Jun 2014 16:56:05 +0000 (UTC) X-MXL-Hash: 5391f2a527041424-1c8a9a2adc721a8f4cc5ad8bec19148ffc114851 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 s56Gu2EV002879; Fri, 6 Jun 2014 12:56:03 -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 s56GtuUs002762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 12:55:58 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 6 Jun 2014 16:55:39 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 12:55:39 -0400 From: "STARK, BARBARA H" To: Sharam Hakimi , "lmap@ietf.org" Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAAc3NAAAXOeXA= Date: Fri, 6 Jun 2014 16:55:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6DBB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B7059377@SPQCMBX01.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7059377@SPQCMBX01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Pb0a8ExErrEA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=gB1ynGRkaxyqhfummwUA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/s3G1nCs6BEMP6yi4J2oRyGLFee0 Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 16:56:24 -0000 > Barbara, >=20 > I understand the intention but I do not think adding another definition w= ill > help in this case. Also a measurement task can be a single or a sequence = of > methods to achieve a single result(even though we have not defied a > sequence yet). >=20 > Sharam I did not suggest adding another definition. I suggested changing the exist= ing definition to better match the way the terms are used most of the time = in lmap drafts, and not to use those terms in ways that do not match the de= finition. The current information model draft version points to exactly one registry = entry for any particular task. This implies that any sequence of events tha= t needs to occur would need to be defined by the registry entry's method. A= lternately, a schedule could have multiple tasks that are sequenced. Your v= iew of a task that can be a sequence of methods is not supported by the cur= rent information model. I think the current information model is fine in th= is regard. Barbara > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Friday, June 06, 2014 9:49 AM > To: lmap@ietf.org > Subject: [lmap] Measurement Methods and Tasks >=20 > Now that it appears we may have resolved the LMAP active/passive debates > (by getting rid of the words) and ambiguity around "which tasks get > suppressed by default", maybe we could agree on what Measurement > Method and Measurement Task are? >=20 > I'd like to propose: > Measurement Method: The process for assessing the value of a Metric; > the process of measuring some performance or reliability parameter > associated with the transfer of traffic; where this process involves m= ultiple > MAs or MPs, each may perform different roles. >=20 > Measurement Task: The act that consists of the single operation of > a Measurement Method role at a particular time and with all its Input > Parameters set to specific values. >=20 > Measurement Method role is not a defined term, but can be used to express > the capability implemented within a MA (or MP) that allows it to particip= ate > in a Measurement Method. I see that various ippm RFCs use the word "role" > in this way, including OWAMP and TWAMP. >=20 > If there is a need to talk about an instance of executing a Measurement > Method, this could be called a Measurement Method instance. Again, > without definition as a formal term. >=20 > There exist several instances of "Measurement Method" that would need to > become "Measurement Method role". For example: > "A Measurement Task is a specific instantiation of a Measurement > Method role." >=20 > Capabilities: Information about the performance measurement > capabilities of the MA, in particular the Measurement Method roles tha= t it > can perform, and the device hosting the MA, for example its interface > type and speed, but not dynamic information. >=20 > "the Measurement Method roles that the MA supports" >=20 > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. >=20 > There is one instance where "Measurement Task capability" is used in the > same sense as a Measurement Method role: "...Measurement Agents may > come from > different vendors, be in wired and wireless networks, have > different Measurement Task capabilities and be on devices with > IPv4 or IPv6 addresses." >=20 > I found one instance where I question the use of "Measurement Task" and > wonder if it should be "Measurement Method": > "Some Measurement Tasks involve several MAs acting in a coordinated > fashion." >=20 > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > Barbara >=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 From nobody Fri Jun 6 10:21: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 628351A0171 for ; Fri, 6 Jun 2014 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 KRdIMv62vmzC for ; Fri, 6 Jun 2014 10:21:35 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9ADA1A016B for ; Fri, 6 Jun 2014 10:21:34 -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 898f1935.2b4916e0a940.10185648.00-2497.25442918.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 06 Jun 2014 17:21:28 +0000 (UTC) X-MXL-Hash: 5391f898300ac7f3-4ce8096beb5cf7279cf65dcd1677023e99b644c0 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 698f1935.0.10185643.00-2285.25442880.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 06 Jun 2014 17:21:27 +0000 (UTC) X-MXL-Hash: 5391f89777797e8e-5d4a4cc1b0a67b7425cd2b54ded289506b351e02 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 s56HLQbY006324; Fri, 6 Jun 2014 13:21:26 -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 s56HLJYg006041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 13:21:20 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 6 Jun 2014 17:21:02 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:21:02 -0400 From: "STARK, BARBARA H" To: "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAKrjAAAAPzgiA= Date: Fri, 6 Jun 2014 17:21:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> In-Reply-To: <5391D622.8060307@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mUbaKL4_SQQA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 a=WIdNqdYV_5eEsVw] X-AnalysisOut: [wF7AA:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA] X-AnalysisOut: [:10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=ujAKXKCihObQf6nZ] X-AnalysisOut: [:21 a=b5-hW4Awu6eiBVlQ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Cc_ZJnOrBfwDM4z-iJhmZMOhWb4 Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 17:21:37 -0000 Hi Charles, I provided a UDP Echo example a week ago. Here is my breakdown of that exam= ple: Measurement Method =3D UDP Echo role 1 =3D UDP Echo Server inputs =3D a port to listen on and a source IP address (MA1 will only = respond to UDP packets from this source IP address) outputs =3D packets and bytes received, packets and bytes sent role 2 =3D UDP Echo Client inputs =3D packet size, destination IP address, time interval between = UDP packets, and number of UDP packets outputs =3D average/max elapsed time between a sent UDP packet and the= response, jitter, etc. If a MA reported its capability to the Controller as "UDP Echo", this would= be ambiguous, because it would mean the MA supported client, server, or bo= th and the Controller has no way of knowing which.=20 If the registry simply listed UDP Echo input parameters as listening port, = source IP address, packet size, destination IP address, time interval betwe= en UDP packets, and number of UDP packets, then the Controller (who has no = information as to which inputs belong to which role or even which role the = MA supports) would need to send values for all of these input parameters to= the MA and hope the MA can pick out the right ones? The Controller would h= ave to tell the MA which role it needed the MA to perform and hope the MA i= s capable of that particular role. I propose that the MA reported capabilities indicate the supported role(s) = of a particular method, and that the registry entries indicate inputs and o= utputs per role. An MA does *not* support UDP Echo. It supports UDP Echo Client or UDP Echo = Server. If both, then the MA reports them to the Controller as separate cap= abilities. Barbara > -----Original Message----- > From: Charles Cook [mailto:charles.cook2@centurylink.com] > Sent: Friday, June 06, 2014 10:54 AM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks >=20 > I agree with Barbara that we need to ensure that we have a clear distinct= ion > between Measurement Method and Measurement Task. >=20 > My view of the Measurement Method is that the Measurement Method is > what is included in a Registry somewhere. The Measurement Method is > essentially a template of a particular type of measurement with a set of > parameters that can be specified. A Measurement Task is an instance of t= he > Measurement Method where specific values have been specified for each of > the parameters in the Measurement Method. Those that are closer to > defining what a Measurement Method is and what a Measurement Task is > can hopefully confirm or clarify as appropriate. >=20 > An MA will need to be able to report to the Controller that it is registe= red to > what capabilities it has relative to what Measurement Methods it can > support. If a MA indicates it can support a particular Measurement Metho= d, > that implies the MA can support the full range of values that can be assi= gned > by the Controller to the parameters of the Measurement Method in the > creation of a Measurement Task. If the MA cannot support the full range = of > values, then the MA cannot claim to support the Measurement Method. >=20 > Even though it may not be within the scope of LMAP, I believe it would be > helpful if someone can propose a sample Measurement Method with all its > parameters as an example that we can use to validate whether the LMAP > framework is adequately complete. Maybe a sample Measurement Method > can be derived from work in ippm (I have not participated in ippm so I do= n't > know if this can be done). >=20 > A sample Measurement Method to exercise the LMAP framework should > help us to: > - determine whether all the bases have been covered in terms of what > functions the LMAP framework needs to support to ensure the execution of > meaningful Measurement Tasks, and > - ensure that a Measurement Method is sufficiently specified to enable > results from multiple executions of a Measurement Task generated from the > Measurement Method to be compared and analyzed in post processing in a > meaningful way. >=20 > Charles >=20 >=20 >=20 >=20 > On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > > Now that it appears we may have resolved the LMAP active/passive > debates (by getting rid of the words) and ambiguity around "which tasks g= et > suppressed by default", maybe we could agree on what Measurement > Method and Measurement Task are? > > > > I'd like to propose: > > Measurement Method: The process for assessing the value of a Metric; > > the process of measuring some performance or reliability parameter > > associated with the transfer of traffic; where this process involves > multiple MAs or MPs, each may perform different roles. > > > > Measurement Task: The act that consists of the single operation of > > a Measurement Method role at a particular time and with all its Inpu= t > > Parameters set to specific values. > > > > Measurement Method role is not a defined term, but can be used to > express the capability implemented within a MA (or MP) that allows it to > participate in a Measurement Method. I see that various ippm RFCs use the > word "role" in this way, including OWAMP and TWAMP. > > > > If there is a need to talk about an instance of executing a Measurement > Method, this could be called a Measurement Method instance. Again, > without definition as a formal term. > > > > There exist several instances of "Measurement Method" that would need > to become "Measurement Method role". For example: > > "A Measurement Task is a specific instantiation of a Measurement > > Method role." > > > > Capabilities: Information about the performance measurement > > capabilities of the MA, in particular the Measurement Method roles t= hat it > > can perform, and the device hosting the MA, for example its interfac= e > > type and speed, but not dynamic information. > > > > "the Measurement Method roles that the MA supports" > > > > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. > > > > There is one instance where "Measurement Task capability" is used in th= e > same sense as a Measurement Method role: "...Measurement Agents may > come from > > different vendors, be in wired and wireless networks, have > > different Measurement Task capabilities and be on devices with > > IPv4 or IPv6 addresses." > > > > I found one instance where I question the use of "Measurement Task" and > wonder if it should be "Measurement Method": > > "Some Measurement Tasks involve several MAs acting in a coordinated > > fashion." > > > > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > > Barbara > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- >=20 > 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 Fri Jun 6 10:38:53 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 3F6311A01ED for ; Fri, 6 Jun 2014 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 a9Y9B6Rsh7aR for ; Fri, 6 Jun 2014 10:38:48 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5D41A01D9 for ; Fri, 6 Jun 2014 10:38:48 -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 2acf1935.2b3f874bb940.580377.00-2474.1626096.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Jun 2014 17:38:42 +0000 (UTC) X-MXL-Hash: 5391fca230f75e51-8a6dd69ffb39f27fd28a77d87039d0c322c0bbc2 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 f9cf1935.0.580333.00-2169.1625959.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 06 Jun 2014 17:38:40 +0000 (UTC) X-MXL-Hash: 5391fca00d06e719-2455f16b04e5bd517b769656651b4b38c6502ee7 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 s56HccSw032039; Fri, 6 Jun 2014 13:38:38 -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 s56HcWCU031946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 13:38:32 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 6 Jun 2014 17:38:15 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:38:15 -0400 From: "STARK, BARBARA H" To: KEN KO , Juergen Schoenwaelder Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMEUiAAAK8W4AABujBEA== Date: Fri, 6 Jun 2014 17:38:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] 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=OMyQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mUbaKL4_SQQA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=vB02jBf7KIiq6-KTHqgA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/dWTpoCqcYJAKg5SJvfj8U7M-tCQ Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 17:38:50 -0000 > With regard to Juergen's preference that references to Measurement > Method be deleted from the framework, I can't go that far. I think > Measurement Methods as a concept are specified in many RFCs and > (hopefully soon to be) referenced via registry entries, and that the > framework should acknowledge this. >=20 > Ken I would also prefer that framework continue to talk about Measurement Metho= d. I do agree with Juergen that it should really be an ippm term. I would p= refer if it were documented in one of the ippm drafts and just pointed to a= nd used by framework. But that dependency might delay framework's publicati= on, so that may not be a practical solution. Barbara From nobody Fri Jun 6 10:53: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 8D6EF1A01EE for ; Fri, 6 Jun 2014 10:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 ugAnOdfooFIt for ; Fri, 6 Jun 2014 10:53:30 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id DA0261A01E4 for ; Fri, 6 Jun 2014 10:53:29 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 517C3A0AC2; Fri, 6 Jun 2014 13:53:22 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 13949A0ABB; Fri, 6 Jun 2014 13:53:22 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.233]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:53:21 -0400 From: Sharam Hakimi To: "STARK, BARBARA H" , KEN KO , "Juergen Schoenwaelder" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMEUiAAAK8W4AABujBEAANU2BQ Date: Fri, 6 Jun 2014 17:53:21 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B7059472@SPQCMBX01.exfo.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.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-20742.001 X-TM-AS-Result: No--8.060-5.0-31-10 X-imss-scan-details: No--8.060-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20742.001 X-TMASE-Result: 10--8.059900-5.000000 X-TMASE-MatchedRID: scwq2vQP8OGhf089fSUphC97pb4g5HCtP3ZrduA3ZZGFiT913RgMLvWn L2FmW8AThYdXC5gTf7ZEZM+mdBeKWSQpWdHXcFatr04R126GsifG8NKjRwUFvPj9/WXpF+Cy/1Q 5H2DyJq52JjoABq8dXuDDGjaTvmA8ue4A1S8vO3phHpATwph+yCNGSJ9zRuUND8kH603DJOCzsu aegZZjxmtWZkGpagwWliXG6TWiBAC0YC3nbjbPMRzwnpmtY/+rfS0Ip2eEHnwc4jS1nsD4HfoLR 4+zsDTtLa13Fo3TPRbSpoNU8DcNKYZFaT/YneWdORwkRq8uPUK9S4QuDTVnFFZca9RSYo/b Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/iyfzzL6vXIMP-j9VVYJkEPyIcpg Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 17:53:32 -0000 A measurement method could include multiple tasks and a task could include = multiple methods. Therefore a single definition would be more appropriate. = Also an MA only understands tasks and the method would only be applicable a= t the controller where tasks are defined and sent to the MA in my opinion. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, June 06, 2014 1:38 PM To: KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks > With regard to Juergen's preference that references to Measurement > Method be deleted from the framework, I can't go that far. I think > Measurement Methods as a concept are specified in many RFCs and > (hopefully soon to be) referenced via registry entries, and that the > framework should acknowledge this. >=20 > Ken I would also prefer that framework continue to talk about Measurement Metho= d. I do agree with Juergen that it should really be an ippm term. I would p= refer if it were documented in one of the ippm drafts and just pointed to a= nd used by framework. But that dependency might delay framework's publicati= on, so that may not be a practical solution. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jun 6 11:05:55 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 81BC81A01D9 for ; Fri, 6 Jun 2014 11:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 9tyv1sC-NKjc for ; Fri, 6 Jun 2014 11:05:49 -0700 (PDT) Received: from p02c11o143.mxlogic.net (p02c11o143.mxlogic.net [208.65.144.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C951A01CB for ; Fri, 6 Jun 2014 11:05:49 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o143.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 7f202935.2ab37fc45940.14276.00-520.38574.p02c11o143.mxlogic.net (envelope-from ); Fri, 06 Jun 2014 12:05:43 -0600 (MDT) X-MXL-Hash: 539202f711264978-14810727bcb7e20e639efedd8dd59e624ab8c708 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o143.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 7a202935.0.13517.00-384.36523.p02c11o143.mxlogic.net (envelope-from ); Fri, 06 Jun 2014 12:04:24 -0600 (MDT) X-MXL-Hash: 539202a874163c62-1273270967a1552f32d2ba43213f3f7885d5a09c Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 13:04:23 -0500 From: KEN KO To: Sharam Hakimi , "STARK, BARBARA H" , Juergen Schoenwaelder Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAOKbmAAAgLyXD//+JMAIAABDqAgABRkJA= Date: Fri, 6 Jun 2014 18:04:21 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B7059472@SPQCMBX01.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B7059472@SPQCMBX01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=N+anFgNB c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=pTHmISxBAAAA:8 a=48vgC7mUAAAA:8 a=gcJlyYwo3r1MuHIcIMo] X-AnalysisOut: [A:9 a=CjuIK1q_8ugA:10 a=DAs2C8GDBtAA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060609); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jFvlcZqtHqdkBjQ2XOus5NhXyaI Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 18:05:51 -0000 First - I don't understand the statement "a task could include multiple met= hods." Can you provide a concrete example? Second - How is the second sentence ("Therefore a single definition would b= e more appropriate.") justified by the first? Even if you accept the first = sentence as a whole, I don't see how it leads to the second. -----Original Message----- From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]=20 Sent: Friday, June 06, 2014 1:53 PM To: STARK, BARBARA H; KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Measurement Methods and Tasks A measurement method could include multiple tasks and a task could include = multiple methods. Therefore a single definition would be more appropriate. = Also an MA only understands tasks and the method would only be applicable a= t the controller where tasks are defined and sent to the MA in my opinion. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, June 06, 2014 1:38 PM To: KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks > With regard to Juergen's preference that references to Measurement=20 > Method be deleted from the framework, I can't go that far. I think=20 > Measurement Methods as a concept are specified in many RFCs and=20 > (hopefully soon to be) referenced via registry entries, and that the=20 > framework should acknowledge this. >=20 > Ken I would also prefer that framework continue to talk about Measurement Metho= d. I do agree with Juergen that it should really be an ippm term. I would p= refer if it were documented in one of the ippm drafts and just pointed to a= nd used by framework. But that dependency might delay framework's publicati= on, so that may not be a practical solution. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jun 6 11:21: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 7E9EA1A01D9 for ; Fri, 6 Jun 2014 11:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 uMUe_6t-lGYy for ; Fri, 6 Jun 2014 11:21:48 -0700 (PDT) Received: from SPQCSVA02.exfo.com (spqcsva02.exfo.com [206.162.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id E68D01A0144 for ; Fri, 6 Jun 2014 11:21:47 -0700 (PDT) Received: from SPQCSVA02.exfo.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C1475A0A09; Fri, 6 Jun 2014 14:21:40 -0400 (EDT) Received: from SPQCCAS.exfo.com (unknown [10.28.36.9]) by SPQCSVA02.exfo.com (Postfix) with ESMTP id 838BFA0A06; Fri, 6 Jun 2014 14:21:40 -0400 (EDT) Received: from SPQCMBX01.exfo.com ([169.254.1.233]) by SPQCCAS02.exfo.com ([10.28.36.9]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 14:21:40 -0400 From: Sharam Hakimi To: KEN KO , "STARK, BARBARA H" , "Juergen Schoenwaelder" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMEUiAAAK8W4AABujBEAANU2BQ//9yM4CAAD968A== Date: Fri, 6 Jun 2014 18:21:39 +0000 Message-ID: <89294A6F3C6C91459E52E4128C4B02B70594E9@SPQCMBX01.exfo.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B7059472@SPQCMBX01.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-20742.001 X-TM-AS-Result: No--9.142-5.0-31-10 X-imss-scan-details: No--9.142-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1017-20742.001 X-TMASE-Result: 10--9.142100-5.000000 X-TMASE-MatchedRID: y/2oPz6gbvgFkDKDVm4Dp2h77jTUbA6yXjZP2MOsiT0utoY2UtFqGBJH AUohrdHEBRFFuKTJ8x3nycS7KFrCfNPYURkTpZRiZlRzaO1xpJ2SuWmlB/ZEFZy1Yc8tPkV9dCq hf9z6M6Ii4bZCUUt3BnvLiXuf0IbeskQ7d8d7LffidvCqqY53aeMBxl40mBj30oGqet6gcqFEz/ Dskxt3RsUrpyGv6ie64lzbiv1ztHT0hDdWAvNPk277LFtuRggWR7ihNqf76IDqHdd93lVj+BZMw fjbmc4Ij1mbw6/tKmuIbw7sIXTQE0qXm4MPqTr2ngIgpj8eDcDInWAWA4yE6ed5J+dpFq4bKrau Xd3MZDXmsNH9Ez2oMpLgy2r8Cy6BZnMa40P+EG7JyeksLLLmC6aenFL+h/3mwL6SxPpr1/I= Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9kHQVvaGc63s9YiKXelbjIrzyyc Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 18:21:49 -0000 A task can be a sequence and one could measure throughput for example with = multiple methods to compare the results.=20 Sharam -----Original Message----- From: KEN KO [mailto:KEN.KO@adtran.com]=20 Sent: Friday, June 06, 2014 2:04 PM To: Sharam Hakimi; STARK, BARBARA H; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Measurement Methods and Tasks First - I don't understand the statement "a task could include multiple met= hods." Can you provide a concrete example? Second - How is the second sentence ("Therefore a single definition would b= e more appropriate.") justified by the first? Even if you accept the first = sentence as a whole, I don't see how it leads to the second. -----Original Message----- From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com]=20 Sent: Friday, June 06, 2014 1:53 PM To: STARK, BARBARA H; KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] Measurement Methods and Tasks A measurement method could include multiple tasks and a task could include = multiple methods. Therefore a single definition would be more appropriate. = Also an MA only understands tasks and the method would only be applicable a= t the controller where tasks are defined and sent to the MA in my opinion. Sharam -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, June 06, 2014 1:38 PM To: KEN KO; Juergen Schoenwaelder Cc: lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks > With regard to Juergen's preference that references to Measurement=20 > Method be deleted from the framework, I can't go that far. I think=20 > Measurement Methods as a concept are specified in many RFCs and=20 > (hopefully soon to be) referenced via registry entries, and that the=20 > framework should acknowledge this. >=20 > Ken I would also prefer that framework continue to talk about Measurement Metho= d. I do agree with Juergen that it should really be an ippm term. I would p= refer if it were documented in one of the ippm drafts and just pointed to a= nd used by framework. But that dependency might delay framework's publicati= on, so that may not be a practical solution. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jun 6 13:00: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 690DB1A0163 for ; Fri, 6 Jun 2014 13:00: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] 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 w1ehyMG7JB60 for ; Fri, 6 Jun 2014 13:00:04 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE9A1A0078 for ; Fri, 6 Jun 2014 13:00:04 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s56Jxtv9018088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 14:59:55 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 3B6C51E005B; Fri, 6 Jun 2014 14:59:50 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 198D91E0058; Fri, 6 Jun 2014 14:59:50 -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 s56JxnUT009453; Fri, 6 Jun 2014 13:59:49 -0600 (MDT) Received: from [10.183.199.129] (x1069818.dhcp.intranet [10.183.199.129]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s56JxmwI009424; Fri, 6 Jun 2014 13:59:48 -0600 (MDT) Message-ID: <53921DB3.8070301@centurylink.com> Date: Fri, 06 Jun 2014 13:59:47 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Enigmail-Version: 1.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/jidcpfxUnI3jVkwZvpo1-YOdS68 Subject: Re: [lmap] Measurement Methods and Tasks 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: Fri, 06 Jun 2014 20:00:09 -0000 Barbara, Thanks. This is a good example, and I think I agree with you. I agree that there needs to be enough information to ensure the MA knows exactly how to run a Measurement Task, and that Measurement Methods and Measurement Tasks need to be sufficiently well defined to avoid any ambiguity. Using "roles", as you suggest in the example, is one way it could be accomplished. Another way it could be accomplished would be to have two Measurement Methods. In your UDP Echo example you could have both a UDP Echo Server Measurement Method, and a UDP Echo Client Measurement Method. However, I think in this case because the UDP Echo Measurement Method has two closely related but different components that need to be orchestrated, I like your concept of "roles". Maybe answer is if a Measurement Method involves more than one MA or MP, then roles need to be identified in the Measurement Method. If the Measurement Method specifies each role and the parameters for each role, then the Controller can specify which MA is to perform which role when it generates a Measurement Task. This requires that the MA needs to report to the Controller which roles it is capable of supporting. All, This is exactly why I would like to see some sample Measurement Methods to exercise the LMAP framework for completeness. I think Barbara's UDP Echo example alone has highlighted some ambiguity that needs to be addressed in the LMAP framework that I did not recognized before. Charles On 6/6/2014 11:21 AM, STARK, BARBARA H wrote: > Hi Charles, > I provided a UDP Echo example a week ago. Here is my breakdown of that example: > Measurement Method = UDP Echo > role 1 = UDP Echo Server > inputs = a port to listen on and a source IP address (MA1 will only respond to UDP packets from this source IP address) > outputs = packets and bytes received, packets and bytes sent > role 2 = UDP Echo Client > inputs = packet size, destination IP address, time interval between UDP packets, and number of UDP packets > outputs = average/max elapsed time between a sent UDP packet and the response, jitter, etc. > > If a MA reported its capability to the Controller as "UDP Echo", this would be ambiguous, because it would mean the MA supported client, server, or both and the Controller has no way of knowing which. > > If the registry simply listed UDP Echo input parameters as listening port, source IP address, packet size, destination IP address, time interval between UDP packets, and number of UDP packets, then the Controller (who has no information as to which inputs belong to which role or even which role the MA supports) would need to send values for all of these input parameters to the MA and hope the MA can pick out the right ones? The Controller would have to tell the MA which role it needed the MA to perform and hope the MA is capable of that particular role. > > I propose that the MA reported capabilities indicate the supported role(s) of a particular method, and that the registry entries indicate inputs and outputs per role. > An MA does *not* support UDP Echo. It supports UDP Echo Client or UDP Echo Server. If both, then the MA reports them to the Controller as separate capabilities. > Barbara > >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: Friday, June 06, 2014 10:54 AM >> To: STARK, BARBARA H; lmap@ietf.org >> Subject: Re: [lmap] Measurement Methods and Tasks >> >> I agree with Barbara that we need to ensure that we have a clear distinction >> between Measurement Method and Measurement Task. >> >> My view of the Measurement Method is that the Measurement Method is >> what is included in a Registry somewhere. The Measurement Method is >> essentially a template of a particular type of measurement with a set of >> parameters that can be specified. A Measurement Task is an instance of the >> Measurement Method where specific values have been specified for each of >> the parameters in the Measurement Method. Those that are closer to >> defining what a Measurement Method is and what a Measurement Task is >> can hopefully confirm or clarify as appropriate. >> >> An MA will need to be able to report to the Controller that it is registered to >> what capabilities it has relative to what Measurement Methods it can >> support. If a MA indicates it can support a particular Measurement Method, >> that implies the MA can support the full range of values that can be assigned >> by the Controller to the parameters of the Measurement Method in the >> creation of a Measurement Task. If the MA cannot support the full range of >> values, then the MA cannot claim to support the Measurement Method. >> >> Even though it may not be within the scope of LMAP, I believe it would be >> helpful if someone can propose a sample Measurement Method with all its >> parameters as an example that we can use to validate whether the LMAP >> framework is adequately complete. Maybe a sample Measurement Method >> can be derived from work in ippm (I have not participated in ippm so I don't >> know if this can be done). >> >> A sample Measurement Method to exercise the LMAP framework should >> help us to: >> - determine whether all the bases have been covered in terms of what >> functions the LMAP framework needs to support to ensure the execution of >> meaningful Measurement Tasks, and >> - ensure that a Measurement Method is sufficiently specified to enable >> results from multiple executions of a Measurement Task generated from the >> Measurement Method to be compared and analyzed in post processing in a >> meaningful way. >> >> Charles >> >> >> >> >> On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: >>> Now that it appears we may have resolved the LMAP active/passive >> debates (by getting rid of the words) and ambiguity around "which tasks get >> suppressed by default", maybe we could agree on what Measurement >> Method and Measurement Task are? >>> I'd like to propose: >>> Measurement Method: The process for assessing the value of a Metric; >>> the process of measuring some performance or reliability parameter >>> associated with the transfer of traffic; where this process involves >> multiple MAs or MPs, each may perform different roles. >>> Measurement Task: The act that consists of the single operation of >>> a Measurement Method role at a particular time and with all its Input >>> Parameters set to specific values. >>> >>> Measurement Method role is not a defined term, but can be used to >> express the capability implemented within a MA (or MP) that allows it to >> participate in a Measurement Method. I see that various ippm RFCs use the >> word "role" in this way, including OWAMP and TWAMP. >>> If there is a need to talk about an instance of executing a Measurement >> Method, this could be called a Measurement Method instance. Again, >> without definition as a formal term. >>> There exist several instances of "Measurement Method" that would need >> to become "Measurement Method role". For example: >>> "A Measurement Task is a specific instantiation of a Measurement >>> Method role." >>> >>> Capabilities: Information about the performance measurement >>> capabilities of the MA, in particular the Measurement Method roles that it >>> can perform, and the device hosting the MA, for example its interface >>> type and speed, but not dynamic information. >>> >>> "the Measurement Method roles that the MA supports" >>> >>> But most discussion of Measurement Method in framework is of the >> Measurement Method and not the Measurement Method role. >>> There is one instance where "Measurement Task capability" is used in the >> same sense as a Measurement Method role: "...Measurement Agents may >> come from >>> different vendors, be in wired and wireless networks, have >>> different Measurement Task capabilities and be on devices with >>> IPv4 or IPv6 addresses." >>> >>> I found one instance where I question the use of "Measurement Task" and >> wonder if it should be "Measurement Method": >>> "Some Measurement Tasks involve several MAs acting in a coordinated >>> fashion." >>> >>> In my scan of framework, I couldn't find a place where I thought >> Measurement Task was used to mean a Measurement Method instance. >>> Barbara >>> >>> _______________________________________________ >>> 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 -- 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 Fri Jun 6 13:03: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 45F971A023E for ; Fri, 6 Jun 2014 13:03: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 In1CI3JOTihJ for ; Fri, 6 Jun 2014 13:03:33 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0429F1A024B for ; Fri, 6 Jun 2014 13:03:32 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s56K3KSL021805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 15:03:21 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7E1E11E0080; Fri, 6 Jun 2014 14:03:15 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 46CFE1E006E; Fri, 6 Jun 2014 14:03:15 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s56K3EjQ019682; Fri, 6 Jun 2014 14:03:14 -0600 (MDT) Received: from [10.183.199.129] (x1069818.dhcp.intranet [10.183.199.129]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s56K3DJV019639; Fri, 6 Jun 2014 14:03:13 -0600 (MDT) Message-ID: <53921E80.5000203@centurylink.com> Date: Fri, 06 Jun 2014 14:03:12 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sharam Hakimi , KEN KO , "STARK, BARBARA H" , Juergen Schoenwaelder References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606153409.GA15246@elstar.local> <2D09D61DDFA73D4C884805CC7865E61130DE6E0A@GAALPA1MSGUSRBF.ITServices.sbc.com> <89294A6F3C6C91459E52E4128C4B02B7059472@SPQCMBX01.exfo.com> <89294A6F3C6C91459E52E4128C4B02B70594E9@SPQCMBX01.exfo.com> In-Reply-To: <89294A6F3C6C91459E52E4128C4B02B70594E9@SPQCMBX01.exfo.com> X-Enigmail-Version: 1.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/kgkKt6AgA_iX20NjwX_Bh_oDsDY Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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: Fri, 06 Jun 2014 20:03:39 -0000 Sharam, My view is that Measurement Methods are the building blocks. Generally a Measurement Task is simply a Measurement Method where the parameters have been filled in. I do see the possibility of creating a Measurement Task that is the combination of more than one Measurement Method. But I do not see the case where a Measurement Method can be composed of Measurement Tasks. Rather, I see a Controller creating multiple Measurement Tasks from the Measurement Methods, and then chaining the Measurement Tasks to be run in the proper order at the proper time. Regarding a Measurement Task composed of multiple Measurement Methods, I do not recall anywhere in the LMAP framework any discussion on how a Measurement Task can be built out of multiple Measurement Methods. The way I interpret the LMAP framework is that if I need to run a measurement that involves two or more Measurement Methods, I would need to create a Measurement Task for each Measurement Method. If we want to be more complex than that, then additional work needs to be done regarding how multiple Measurement Methods can be combined into a single Measurement Task in such a way that the MA will have the capability to run the new complex Measurement Task. Basically what I am saying is that I believe that an MA may have the resources to run a Measurement Task generated from Measurement Method A by itself and the MA may have the resources to run a Measurement Task generated from Measurement Method B by itself, but the MA may not have the resources to run a Measurement Task that combines Measurement Method A and Measurement Method B. I'm not opposed to expanding the LMAP framework to address more complex Measurement Tasks, but unless we have more definition on how multiple Measurement Methods can be combined into a single Measurement Task without exceeding the capabilities of the MA, my preference would be to define additional Measurement Methods and maintain a one-to-one mapping between Measurement Methods and Measurement Tasks. Charles On 6/6/2014 12:21 PM, Sharam Hakimi wrote: > A task can be a sequence and one could measure throughput for example with multiple methods to compare the results. > > Sharam > > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Friday, June 06, 2014 2:04 PM > To: Sharam Hakimi; STARK, BARBARA H; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] Measurement Methods and Tasks > > First - I don't understand the statement "a task could include multiple methods." Can you provide a concrete example? > > Second - How is the second sentence ("Therefore a single definition would be more appropriate.") justified by the first? Even if you accept the first sentence as a whole, I don't see how it leads to the second. > > -----Original Message----- > From: Sharam Hakimi [mailto:sharam.hakimi@exfo.com] > Sent: Friday, June 06, 2014 1:53 PM > To: STARK, BARBARA H; KEN KO; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] Measurement Methods and Tasks > > A measurement method could include multiple tasks and a task could include multiple methods. Therefore a single definition would be more appropriate. Also an MA only understands tasks and the method would only be applicable at the controller where tasks are defined and sent to the MA in my opinion. > > > Sharam > > > > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Friday, June 06, 2014 1:38 PM > To: KEN KO; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks > >> With regard to Juergen's preference that references to Measurement >> Method be deleted from the framework, I can't go that far. I think >> Measurement Methods as a concept are specified in many RFCs and >> (hopefully soon to be) referenced via registry entries, and that the >> framework should acknowledge this. >> >> Ken > I would also prefer that framework continue to talk about Measurement Method. I do agree with Juergen that it should really be an ippm term. I would prefer if it were documented in one of the ippm drafts and just pointed to and used by framework. But that dependency might delay framework's publication, so that may not be a practical solution. > 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 -- 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 Fri Jun 6 13:20:48 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 952D31A0268 for ; Fri, 6 Jun 2014 13:20:45 -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 cOa9EH70iHme for ; Fri, 6 Jun 2014 13:20:43 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2271A00FC for ; Fri, 6 Jun 2014 13:20:43 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so3716689vcb.17 for ; Fri, 06 Jun 2014 13:20:35 -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=PsyegpE6xwi9IT5JGcbe1ZN55i7Bw8uIyALItOstl8c=; b=PhszGVfK7pSUQA4frn65eltpZt4TUNVQJqFQouKioypYm5/JN6ALhOAMZZbaeEf1Lt wK89ZqvDYdeSesS9TUiijxHVRFumIglueIB2HAfN19e/WU1c1rnHQPiuaEt6x82QPqqq qi3M4yJLa75Keubxpom6XIxfY8d3zhnQ3Fuu/s18becnN+7oZFbD7zSADd33WlsAvSSe bvQMRMUqeHFEAhHfk6IQAGV7AycSbvgFGw3QyXr3M8f7y00o0IpOQR1apqgy5Unh5I/C uBPx0xXEx6mO/3NHFrMmY64wVQp9bsSoiT77v8BTJEGu/UMfP+pl7ecFS0K/KSp0wWMN BjKg== MIME-Version: 1.0 X-Received: by 10.220.98.143 with SMTP id q15mr6524710vcn.38.1402086035782; Fri, 06 Jun 2014 13:20:35 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 6 Jun 2014 13:20:35 -0700 (PDT) In-Reply-To: <5391D622.8060307@centurylink.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> Date: Fri, 6 Jun 2014 13:20:35 -0700 Message-ID: From: Greg Mirsky To: Charles Cook Content-Type: multipart/alternative; boundary=001a11c1da061b833904fb309899 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/h-HMJ2M-WWdRf5VnjSiGc5J1g3k Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 20:20:45 -0000 --001a11c1da061b833904fb309899 Content-Type: text/plain; charset=UTF-8 Hi Charles, though discussion of what level of support of particular Measurement Method by an MA is acceptable seems premature and more appropriate to discussion of Control Protocol, I'd like to note that I cannot agree with your suggestion: "If the MA cannot support the full range of values, then the MA cannot claim to support the Measurement Method." Regards, Greg On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook wrote: > I agree with Barbara that we need to ensure that we have a clear > distinction between Measurement Method and Measurement Task. > > My view of the Measurement Method is that the Measurement Method is what > is included in a Registry somewhere. The Measurement Method is > essentially a template of a particular type of measurement with a set of > parameters that can be specified. A Measurement Task is an instance of > the Measurement Method where specific values have been specified for > each of the parameters in the Measurement Method. Those that are closer > to defining what a Measurement Method is and what a Measurement Task is > can hopefully confirm or clarify as appropriate. > > An MA will need to be able to report to the Controller that it is > registered to what capabilities it has relative to what Measurement > Methods it can support. If a MA indicates it can support a particular > Measurement Method, that implies the MA can support the full range of > values that can be assigned by the Controller to the parameters of the > Measurement Method in the creation of a Measurement Task. If the MA > cannot support the full range of values, then the MA cannot claim to > support the Measurement Method. > > Even though it may not be within the scope of LMAP, I believe it would > be helpful if someone can propose a sample Measurement Method with all > its parameters as an example that we can use to validate whether the > LMAP framework is adequately complete. Maybe a sample Measurement > Method can be derived from work in ippm (I have not participated in ippm > so I don't know if this can be done). > > A sample Measurement Method to exercise the LMAP framework should help > us to: > - determine whether all the bases have been covered in terms of what > functions the LMAP framework needs to support to ensure the execution of > meaningful Measurement Tasks, and > - ensure that a Measurement Method is sufficiently specified to enable > results from multiple executions of a Measurement Task generated from > the Measurement Method to be compared and analyzed in post processing in > a meaningful way. > > Charles > > > > > On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > > Now that it appears we may have resolved the LMAP active/passive debates > (by getting rid of the words) and ambiguity around "which tasks get > suppressed by default", maybe we could agree on what Measurement Method and > Measurement Task are? > > > > I'd like to propose: > > Measurement Method: The process for assessing the value of a Metric; > > the process of measuring some performance or reliability parameter > > associated with the transfer of traffic; where this process involves > multiple MAs or MPs, each may perform different roles. > > > > Measurement Task: The act that consists of the single operation of > > a Measurement Method role at a particular time and with all its Input > > Parameters set to specific values. > > > > Measurement Method role is not a defined term, but can be used to > express the capability implemented within a MA (or MP) that allows it to > participate in a Measurement Method. I see that various ippm RFCs use the > word "role" in this way, including OWAMP and TWAMP. > > > > If there is a need to talk about an instance of executing a Measurement > Method, this could be called a Measurement Method instance. Again, without > definition as a formal term. > > > > There exist several instances of "Measurement Method" that would need to > become "Measurement Method role". For example: > > "A Measurement Task is a specific instantiation of a Measurement > > Method role." > > > > Capabilities: Information about the performance measurement > > capabilities of the MA, in particular the Measurement Method roles > that it > > can perform, and the device hosting the MA, for example its interface > > type and speed, but not dynamic information. > > > > "the Measurement Method roles that the MA supports" > > > > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. > > > > There is one instance where "Measurement Task capability" is used in the > same sense as a Measurement Method role: "...Measurement Agents may come > from > > different vendors, be in wired and wireless networks, have > > different Measurement Task capabilities and be on devices with > > IPv4 or IPv6 addresses." > > > > I found one instance where I question the use of "Measurement Task" and > wonder if it should be "Measurement Method": > > "Some Measurement Tasks involve several MAs acting in a coordinated > > fashion." > > > > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > > Barbara > > > > _______________________________________________ > > 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 > --001a11c1da061b833904fb309899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charles,
though discussion of w= hat level of support of particular Measurement Method by an MA is acceptabl= e seems premature and more appropriate to discussion of Control Protocol, I= 'd like to note that I cannot agree with your suggestion: "If the = MA
cannot support the full range of values, then the MA cannot claim to suppor= t the Measurement Method."

Regards,
Greg




On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook <cha= rles.cook2@centurylink.com> wrote:
I agree with Barbara that we need to ensure = that we have a clear
distinction between Measurement Method and Measurement Task.

My view of the Measurement Method is that the Measurement Method is what is included in a Registry somewhere. =C2=A0The Measurement Method is
essentially a template of a particular type of measurement with a set of parameters that can be specified. =C2=A0A Measurement Task is an instance o= f
the Measurement Method where specific values have been specified for
each of the parameters in the Measurement Method. =C2=A0Those that are clos= er
to defining what a Measurement Method is and what a Measurement Task is
can hopefully confirm or clarify as appropriate.

An MA will need to be able to report to the Controller that it is
registered to what capabilities it has relative to what Measurement
Methods it can support. =C2=A0If a MA indicates it can support a particular=
Measurement Method, that implies the MA can support the full range of
values that can be assigned by the Controller to the parameters of the
Measurement Method in the creation of a Measurement Task. =C2=A0If the MA cannot support the full range of values, then the MA cannot claim to
support the Measurement Method.

Even though it may not be within the scope of LMAP, I believe it would
be helpful if someone can propose a sample Measurement Method with all
its parameters as an example that we can use to validate whether the
LMAP framework is adequately complete. =C2=A0Maybe a sample Measurement
Method can be derived from work in ippm (I have not participated in ippm so I don't know if this can be done).

A sample Measurement Method to exercise the LMAP framework should help
us to:
- determine whether all the bases have been covered in terms of what
functions the LMAP framework needs to support to ensure the execution of meaningful Measurement Tasks, and
- ensure that a Measurement Method is sufficiently specified to enable
results from multiple executions of a Measurement Task generated from
the Measurement Method to be compared and analyzed in post processing in a meaningful way.

Charles




On 6/6/2014 7:48 AM, STARK, BARBARA H wrote:
> Now that it appears we may have resolved the LMAP active/passive debat= es (by getting rid of the words) and ambiguity around "which tasks get= suppressed by default", maybe we could agree on what Measurement Meth= od and Measurement Task are?
>
> I'd like to propose:
> =C2=A0 =C2=A0Measurement Method: The process for assessing the value o= f a Metric;
> =C2=A0 =C2=A0the process of measuring some performance or reliability = parameter
> =C2=A0 =C2=A0associated with the transfer of traffic; where this proce= ss involves multiple MAs or MPs, each may perform different roles.
>
> =C2=A0 =C2=A0Measurement Task: The act that consists of the single ope= ration of
> =C2=A0 =C2=A0a Measurement Method role at a particular time and with a= ll its Input
> =C2=A0 =C2=A0Parameters set to specific values.
>
> Measurement Method role is not a defined term, but can be used to expr= ess the capability implemented within a MA (or MP) that allows it to partic= ipate in a Measurement Method. I see that various ippm RFCs use the word &q= uot;role" in this way, including OWAMP and TWAMP.
>
> If there is a need to talk about an instance of executing a Measuremen= t Method, this could be called a Measurement Method instance. Again, withou= t definition as a formal term.
>
> There exist several instances of "Measurement Method" that w= ould need to become "Measurement Method role". For example:
> =C2=A0 =C2=A0"A Measurement Task is a specific instantiation of a= Measurement
> =C2=A0 =C2=A0Method role."
>
> =C2=A0 =C2=A0Capabilities: Information about the performance measureme= nt
> =C2=A0 =C2=A0capabilities of the MA, in particular the Measurement Met= hod roles that it
> =C2=A0 =C2=A0can perform, and the device hosting the MA, for example i= ts interface
> =C2=A0 =C2=A0type and speed, but not dynamic information.
>
> "the Measurement Method roles that the MA supports"
>
> But most discussion of Measurement Method in framework is of the Measu= rement Method and not the Measurement Method role.
>
> There is one instance where "Measurement Task capability" is= used in the same sense as a Measurement Method role: "...Measurement = Agents may come from
> =C2=A0 =C2=A0 =C2=A0 different vendors, be in wired and wireless netwo= rks, have
> =C2=A0 =C2=A0 =C2=A0 different Measurement Task capabilities and be on= devices with
> =C2=A0 =C2=A0 =C2=A0 IPv4 or IPv6 addresses."
>
> I found one instance where I question the use of "Measurement Tas= k" and wonder if it should be "Measurement Method":
> =C2=A0 =C2=A0"Some Measurement Tasks involve several MAs acting i= n a coordinated
> =C2=A0 =C2=A0fashion."
>
> In my scan of framework, I couldn't find a place where I thought M= easurement Task was used to mean a Measurement Method instance.
> Barbara
>
> _______________________________________________
> 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 =C2=A080221
Tel: =C2=A0303.992.8952= =C2=A0Fax: =C2=A09= 25.281.0662
charles.cook2@centurylink.= com

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

--001a11c1da061b833904fb309899-- From nobody Fri Jun 6 13:55:03 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 234501A029B for ; Fri, 6 Jun 2014 13:55:01 -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, HTML_MESSAGE=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 d0gAfq4aRaxf for ; Fri, 6 Jun 2014 13:54:57 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1371A027C for ; Fri, 6 Jun 2014 13:54:57 -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 s56Ksk5P017500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 14:54:46 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 84A881E0053; Fri, 6 Jun 2014 14:54:41 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 574471E004D; Fri, 6 Jun 2014 14:54:41 -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 s56KseP8006714; Fri, 6 Jun 2014 15:54:40 -0500 (CDT) Received: from [10.183.199.129] (x1069818.dhcp.intranet [10.183.199.129]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s56Ksd0x006697; Fri, 6 Jun 2014 15:54:39 -0500 (CDT) Message-ID: <53922A8E.7050100@centurylink.com> Date: Fri, 06 Jun 2014 14:54:38 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Greg Mirsky References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010608000207080608080003" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/M1qDJJqDsYZNB685UHa5hrLU_LU Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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: Fri, 06 Jun 2014 20:55:01 -0000 This is a multi-part message in MIME format. --------------010608000207080608080003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Greg, It may be a question of what level of granularity does a MA need to report its capabilities. The simplest would be a scenario where the MA reports a list of Measurement Methods that it supports upon registration with the Controller. If the MA is able to also report supported parameter ranges of each supported Measurement Method, then this can be effectively addressed. Perhaps the LMAP framework can provide more information on what level of detail the MA needs to report. It may also depend on whether the MA simply informs the Controller of its capabilities as a list, or whether there is a negotiation protocol where the Controller can query the MA for additional details of its capabilities. For example, upon registration the MA can provide a list of supported Measurement Methods. Then at some later point, the Controller through some protocol can query the MA relative to the range that can be supported for each parameter in the Measurement Method of interest. Because I am of the opinion that if MAs are to be implementable in devices that could include modems and residential gateways at the customer premises, cost becomes an issue. In other words, I want the ability to add MA functionality to a modem or residential gateway to be a simple as possible, and the cost to be as low as possible. So my thoughts will generally come from the perspective of minimizing protocol complexity. Consequently, I had the list reporting approach upon registration in mind. But now that you mention it, I can see how the LMAP framework can be interpreted to allow an MA to report that it can support a given Measurement Method even though it may not support the full range of valid values for each parameter. That said, I can back off of my original statement of, "If the MA cannot support the full range of values, then the MA cannot claim to support the Measurement Method." However, I would like to see some text in LMAP to elaborate on this topic. I think this discussion also highlights the need for the protocol work to be done so that LMAP can point to it. Charles On 6/6/2014 2:20 PM, Greg Mirsky wrote: > Hi Charles, > though discussion of what level of support of particular Measurement > Method by an MA is acceptable seems premature and more appropriate to > discussion of Control Protocol, I'd like to note that I cannot agree > with your suggestion: "If the MA > cannot support the full range of values, then the MA cannot claim to > support the Measurement Method." > > Regards, > Greg > > > > > On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook > > > wrote: > > I agree with Barbara that we need to ensure that we have a clear > distinction between Measurement Method and Measurement Task. > > My view of the Measurement Method is that the Measurement Method > is what > is included in a Registry somewhere. The Measurement Method is > essentially a template of a particular type of measurement with a > set of > parameters that can be specified. A Measurement Task is an > instance of > the Measurement Method where specific values have been specified for > each of the parameters in the Measurement Method. Those that are > closer > to defining what a Measurement Method is and what a Measurement > Task is > can hopefully confirm or clarify as appropriate. > > An MA will need to be able to report to the Controller that it is > registered to what capabilities it has relative to what Measurement > Methods it can support. If a MA indicates it can support a particular > Measurement Method, that implies the MA can support the full range of > values that can be assigned by the Controller to the parameters of the > Measurement Method in the creation of a Measurement Task. If the MA > cannot support the full range of values, then the MA cannot claim to > support the Measurement Method. > > Even though it may not be within the scope of LMAP, I believe it would > be helpful if someone can propose a sample Measurement Method with all > its parameters as an example that we can use to validate whether the > LMAP framework is adequately complete. Maybe a sample Measurement > Method can be derived from work in ippm (I have not participated > in ippm > so I don't know if this can be done). > > A sample Measurement Method to exercise the LMAP framework should help > us to: > - determine whether all the bases have been covered in terms of what > functions the LMAP framework needs to support to ensure the > execution of > meaningful Measurement Tasks, and > - ensure that a Measurement Method is sufficiently specified to enable > results from multiple executions of a Measurement Task generated from > the Measurement Method to be compared and analyzed in post > processing in > a meaningful way. > > Charles > > > > > On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > > Now that it appears we may have resolved the LMAP active/passive > debates (by getting rid of the words) and ambiguity around "which > tasks get suppressed by default", maybe we could agree on what > Measurement Method and Measurement Task are? > > > > I'd like to propose: > > Measurement Method: The process for assessing the value of a > Metric; > > the process of measuring some performance or reliability > parameter > > associated with the transfer of traffic; where this process > involves multiple MAs or MPs, each may perform different roles. > > > > Measurement Task: The act that consists of the single > operation of > > a Measurement Method role at a particular time and with all > its Input > > Parameters set to specific values. > > > > Measurement Method role is not a defined term, but can be used > to express the capability implemented within a MA (or MP) that > allows it to participate in a Measurement Method. I see that > various ippm RFCs use the word "role" in this way, including OWAMP > and TWAMP. > > > > If there is a need to talk about an instance of executing a > Measurement Method, this could be called a Measurement Method > instance. Again, without definition as a formal term. > > > > There exist several instances of "Measurement Method" that would > need to become "Measurement Method role". For example: > > "A Measurement Task is a specific instantiation of a Measurement > > Method role." > > > > Capabilities: Information about the performance measurement > > capabilities of the MA, in particular the Measurement Method > roles that it > > can perform, and the device hosting the MA, for example its > interface > > type and speed, but not dynamic information. > > > > "the Measurement Method roles that the MA supports" > > > > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. > > > > There is one instance where "Measurement Task capability" is > used in the same sense as a Measurement Method role: > "...Measurement Agents may come from > > different vendors, be in wired and wireless networks, have > > different Measurement Task capabilities and be on devices with > > IPv4 or IPv6 addresses." > > > > I found one instance where I question the use of "Measurement > Task" and wonder if it should be "Measurement Method": > > "Some Measurement Tasks involve several MAs acting in a > coordinated > > fashion." > > > > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > > Barbara > > > > _______________________________________________ > > 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 --------------010608000207080608080003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Greg,

It may be a question of what level of granularity does a MA need to report its capabilities.  The simplest would be a scenario where the MA reports a list of Measurement Methods that it supports upon registration with the Controller.  If the MA is able to also report supported parameter ranges of each supported Measurement Method, then this can be effectively addressed.  Perhaps the LMAP framework can provide more information on what level of detail the MA needs to report.

It may also depend on whether the MA simply informs the Controller of its capabilities as a list, or whether there is a negotiation protocol where the Controller can query the MA for additional details of its capabilities.  For example, upon registration the MA can provide a list of supported Measurement Methods.  Then at some later point, the Controller through some protocol can query the MA relative to the range that can be supported for each parameter in the Measurement Method of interest. 

Because I am of the opinion that if MAs are to be implementable in devices that could include modems and residential gateways at the customer premises, cost becomes an issue.  In other words, I want the ability to add MA functionality to a modem or residential gateway to be a simple as possible, and the cost to be as low as possible.   So my thoughts will generally come from the perspective of minimizing protocol complexity.  Consequently, I had the list reporting approach upon registration in mind.  But now that you mention it, I can see how the LMAP framework can be interpreted to allow an MA to report that it can support a given Measurement Method even though it may not support the full range of valid values for each parameter. 

That said, I can back off of my original statement of, "If the MA cannot support the full range of values, then the MA cannot claim to support the Measurement Method."  However, I would like to see some text in LMAP to elaborate on this topic.  I think this discussion also highlights the need for the protocol work to be done so that LMAP can point to it.

Charles


On 6/6/2014 2:20 PM, Greg Mirsky wrote:
Hi Charles,
though discussion of what level of support of particular Measurement Method by an MA is acceptable seems premature and more appropriate to discussion of Control Protocol, I'd like to note that I cannot agree with your suggestion: "If the MA
cannot support the full range of values, then the MA cannot claim to support the Measurement Method."

Regards,
Greg




On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook <charles.cook2@centurylink.com> wrote:
I agree with Barbara that we need to ensure that we have a clear
distinction between Measurement Method and Measurement Task.

My view of the Measurement Method is that the Measurement Method is what
is included in a Registry somewhere.  The Measurement Method is
essentially a template of a particular type of measurement with a set of
parameters that can be specified.  A Measurement Task is an instance of
the Measurement Method where specific values have been specified for
each of the parameters in the Measurement Method.  Those that are closer
to defining what a Measurement Method is and what a Measurement Task is
can hopefully confirm or clarify as appropriate.

An MA will need to be able to report to the Controller that it is
registered to what capabilities it has relative to what Measurement
Methods it can support.  If a MA indicates it can support a particular
Measurement Method, that implies the MA can support the full range of
values that can be assigned by the Controller to the parameters of the
Measurement Method in the creation of a Measurement Task.  If the MA
cannot support the full range of values, then the MA cannot claim to
support the Measurement Method.

Even though it may not be within the scope of LMAP, I believe it would
be helpful if someone can propose a sample Measurement Method with all
its parameters as an example that we can use to validate whether the
LMAP framework is adequately complete.  Maybe a sample Measurement
Method can be derived from work in ippm (I have not participated in ippm
so I don't know if this can be done).

A sample Measurement Method to exercise the LMAP framework should help
us to:
- determine whether all the bases have been covered in terms of what
functions the LMAP framework needs to support to ensure the execution of
meaningful Measurement Tasks, and
- ensure that a Measurement Method is sufficiently specified to enable
results from multiple executions of a Measurement Task generated from
the Measurement Method to be compared and analyzed in post processing in
a meaningful way.

Charles




On 6/6/2014 7:48 AM, STARK, BARBARA H wrote:
> Now that it appears we may have resolved the LMAP active/passive debates (by getting rid of the words) and ambiguity around "which tasks get suppressed by default", maybe we could agree on what Measurement Method and Measurement Task are?
>
> I'd like to propose:
>    Measurement Method: The process for assessing the value of a Metric;
>    the process of measuring some performance or reliability parameter
>    associated with the transfer of traffic; where this process involves multiple MAs or MPs, each may perform different roles.
>
>    Measurement Task: The act that consists of the single operation of
>    a Measurement Method role at a particular time and with all its Input
>    Parameters set to specific values.
>
> Measurement Method role is not a defined term, but can be used to express the capability implemented within a MA (or MP) that allows it to participate in a Measurement Method. I see that various ippm RFCs use the word "role" in this way, including OWAMP and TWAMP.
>
> If there is a need to talk about an instance of executing a Measurement Method, this could be called a Measurement Method instance. Again, without definition as a formal term.
>
> There exist several instances of "Measurement Method" that would need to become "Measurement Method role". For example:
>    "A Measurement Task is a specific instantiation of a Measurement
>    Method role."
>
>    Capabilities: Information about the performance measurement
>    capabilities of the MA, in particular the Measurement Method roles that it
>    can perform, and the device hosting the MA, for example its interface
>    type and speed, but not dynamic information.
>
> "the Measurement Method roles that the MA supports"
>
> But most discussion of Measurement Method in framework is of the Measurement Method and not the Measurement Method role.
>
> There is one instance where "Measurement Task capability" is used in the same sense as a Measurement Method role: "...Measurement Agents may come from
>       different vendors, be in wired and wireless networks, have
>       different Measurement Task capabilities and be on devices with
>       IPv4 or IPv6 addresses."
>
> I found one instance where I question the use of "Measurement Task" and wonder if it should be "Measurement Method":
>    "Some Measurement Tasks involve several MAs acting in a coordinated
>    fashion."
>
> In my scan of framework, I couldn't find a place where I thought Measurement Task was used to mean a Measurement Method instance.
> Barbara
>
> _______________________________________________
> 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
--------------010608000207080608080003-- From nobody Fri Jun 6 14:15: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 4444C1A0290 for ; Fri, 6 Jun 2014 14:14:58 -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 MPFge5oLvVGf for ; Fri, 6 Jun 2014 14:14:54 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFE11A0274 for ; Fri, 6 Jun 2014 14:14:54 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so2060893vcb.2 for ; Fri, 06 Jun 2014 14:14:46 -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=M31xdCxrCiGkdaRofWw27fw3lmxiExsQo+9ez1ve9cA=; b=0uXKYu4r3/ADRdXap1vL4TGqbssOXDQkcTZlMvFyLsWCnZdpVAKSpXYQ77iV4fzlrG CozdxFlKm66jEH1UpWRxWHYikuDJdNT4iQ1SJxbMNDQ9t/UEzB+zXOgZ7/2vd5w6lW8K 2iaV6r06v+nYTHnWR3sv7QHLH7OvSJX2RtmcSxMlx69pDjovc2SYQhScZIucf68aVAHz YkeAkofszbcustrNViSEUW5SLXlXxn6ooGqpTXf1IZxgbAEmKa/JGm1XDa9QH+6rLFjz IzF/PWsqOw9Hq5YQ5eKmLWgDWf4t6/XBR7GMdNLxd45Exb+e5AMaHItikZ7RFXYPU0Z1 IKrg== MIME-Version: 1.0 X-Received: by 10.220.98.143 with SMTP id q15mr6823814vcn.38.1402089286848; Fri, 06 Jun 2014 14:14:46 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 6 Jun 2014 14:14:46 -0700 (PDT) In-Reply-To: <53922A8E.7050100@centurylink.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> <53922A8E.7050100@centurylink.com> Date: Fri, 6 Jun 2014 14:14:46 -0700 Message-ID: From: Greg Mirsky To: Charles Cook Content-Type: multipart/alternative; boundary=001a11c1da06e2d86e04fb3159c0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zlBe85LvBwKtX0myoIweU-KbDB8 Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] Measurement Methods and Tasks 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, 06 Jun 2014 21:14:58 -0000 --001a11c1da06e2d86e04fb3159c0 Content-Type: text/plain; charset=UTF-8 Hi Charles, " I think this discussion also highlights the need for the protocol work to be done so that LMAP can point to it." wholeheartedly agree and enthusiastically support. Regards, Greg On Fri, Jun 6, 2014 at 1:54 PM, Charles Cook wrote: > Greg, > > It may be a question of what level of granularity does a MA need to report > its capabilities. The simplest would be a scenario where the MA reports a > list of Measurement Methods that it supports upon registration with the > Controller. If the MA is able to also report supported parameter ranges of > each supported Measurement Method, then this can be effectively addressed. > Perhaps the LMAP framework can provide more information on what level of > detail the MA needs to report. > > It may also depend on whether the MA simply informs the Controller of its > capabilities as a list, or whether there is a negotiation protocol where > the Controller can query the MA for additional details of its > capabilities. For example, upon registration the MA can provide a list of > supported Measurement Methods. Then at some later point, the Controller > through some protocol can query the MA relative to the range that can be > supported for each parameter in the Measurement Method of interest. > > Because I am of the opinion that if MAs are to be implementable in devices > that could include modems and residential gateways at the customer > premises, cost becomes an issue. In other words, I want the ability to add > MA functionality to a modem or residential gateway to be a simple as > possible, and the cost to be as low as possible. So my thoughts will > generally come from the perspective of minimizing protocol complexity. > Consequently, I had the list reporting approach upon registration in mind. > But now that you mention it, I can see how the LMAP framework can be > interpreted to allow an MA to report that it can support a given > Measurement Method even though it may not support the full range of valid > values for each parameter. > > That said, I can back off of my original statement of, "If the MA cannot > support the full range of values, then the MA cannot claim to support the > Measurement Method." However, I would like to see some text in LMAP to > elaborate on this topic. I think this discussion also highlights the need > for the protocol work to be done so that LMAP can point to it. > > Charles > > > > On 6/6/2014 2:20 PM, Greg Mirsky wrote: > > Hi Charles, > though discussion of what level of support of particular Measurement > Method by an MA is acceptable seems premature and more appropriate to > discussion of Control Protocol, I'd like to note that I cannot agree with > your suggestion: "If the MA > cannot support the full range of values, then the MA cannot claim to > support the Measurement Method." > > Regards, > Greg > > > > > On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook < > charles.cook2@centurylink.com> wrote: > >> I agree with Barbara that we need to ensure that we have a clear >> distinction between Measurement Method and Measurement Task. >> >> My view of the Measurement Method is that the Measurement Method is what >> is included in a Registry somewhere. The Measurement Method is >> essentially a template of a particular type of measurement with a set of >> parameters that can be specified. A Measurement Task is an instance of >> the Measurement Method where specific values have been specified for >> each of the parameters in the Measurement Method. Those that are closer >> to defining what a Measurement Method is and what a Measurement Task is >> can hopefully confirm or clarify as appropriate. >> >> An MA will need to be able to report to the Controller that it is >> registered to what capabilities it has relative to what Measurement >> Methods it can support. If a MA indicates it can support a particular >> Measurement Method, that implies the MA can support the full range of >> values that can be assigned by the Controller to the parameters of the >> Measurement Method in the creation of a Measurement Task. If the MA >> cannot support the full range of values, then the MA cannot claim to >> support the Measurement Method. >> >> Even though it may not be within the scope of LMAP, I believe it would >> be helpful if someone can propose a sample Measurement Method with all >> its parameters as an example that we can use to validate whether the >> LMAP framework is adequately complete. Maybe a sample Measurement >> Method can be derived from work in ippm (I have not participated in ippm >> so I don't know if this can be done). >> >> A sample Measurement Method to exercise the LMAP framework should help >> us to: >> - determine whether all the bases have been covered in terms of what >> functions the LMAP framework needs to support to ensure the execution of >> meaningful Measurement Tasks, and >> - ensure that a Measurement Method is sufficiently specified to enable >> results from multiple executions of a Measurement Task generated from >> the Measurement Method to be compared and analyzed in post processing in >> a meaningful way. >> >> Charles >> >> >> >> >> On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: >> > Now that it appears we may have resolved the LMAP active/passive >> debates (by getting rid of the words) and ambiguity around "which tasks get >> suppressed by default", maybe we could agree on what Measurement Method and >> Measurement Task are? >> > >> > I'd like to propose: >> > Measurement Method: The process for assessing the value of a Metric; >> > the process of measuring some performance or reliability parameter >> > associated with the transfer of traffic; where this process involves >> multiple MAs or MPs, each may perform different roles. >> > >> > Measurement Task: The act that consists of the single operation of >> > a Measurement Method role at a particular time and with all its Input >> > Parameters set to specific values. >> > >> > Measurement Method role is not a defined term, but can be used to >> express the capability implemented within a MA (or MP) that allows it to >> participate in a Measurement Method. I see that various ippm RFCs use the >> word "role" in this way, including OWAMP and TWAMP. >> > >> > If there is a need to talk about an instance of executing a Measurement >> Method, this could be called a Measurement Method instance. Again, without >> definition as a formal term. >> > >> > There exist several instances of "Measurement Method" that would need >> to become "Measurement Method role". For example: >> > "A Measurement Task is a specific instantiation of a Measurement >> > Method role." >> > >> > Capabilities: Information about the performance measurement >> > capabilities of the MA, in particular the Measurement Method roles >> that it >> > can perform, and the device hosting the MA, for example its interface >> > type and speed, but not dynamic information. >> > >> > "the Measurement Method roles that the MA supports" >> > >> > But most discussion of Measurement Method in framework is of the >> Measurement Method and not the Measurement Method role. >> > >> > There is one instance where "Measurement Task capability" is used in >> the same sense as a Measurement Method role: "...Measurement Agents may >> come from >> > different vendors, be in wired and wireless networks, have >> > different Measurement Task capabilities and be on devices with >> > IPv4 or IPv6 addresses." >> > >> > I found one instance where I question the use of "Measurement Task" and >> wonder if it should be "Measurement Method": >> > "Some Measurement Tasks involve several MAs acting in a coordinated >> > fashion." >> > >> > In my scan of framework, I couldn't find a place where I thought >> Measurement Task was used to mean a Measurement Method instance. >> > Barbara >> > >> > _______________________________________________ >> > 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.0662charles.cook2@centurylink.com > > --001a11c1da06e2d86e04fb3159c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charles,
" I think this discussi= on also highlights the need for the protocol work to be done so that LMAP can point to it."
wholeheartedly agree and enthusias= tically support.

Regards,
Greg


On Fri, Jun 6, 2014 at 1:5= 4 PM, Charles Cook <charles.cook2@centurylink.com> wrote:
=20 =20 =20
Greg,

It may be a question of what level of granularity does a MA need to report its capabilities.=C2=A0 The simplest would be a scenario where t= he MA reports a list of Measurement Methods that it supports upon registration with the Controller.=C2=A0 If the MA is able to also repor= t supported parameter ranges of each supported Measurement Method, then this can be effectively addressed.=C2=A0 Perhaps the LMAP framewor= k can provide more information on what level of detail the MA needs to report.

It may also depend on whether the MA simply informs the Controller of its capabilities as a list, or whether there is a negotiation protocol where the Controller can query the MA for additional details of its capabilities.=C2=A0 For example, upon registration the M= A can provide a list of supported Measurement Methods.=C2=A0 Then at some later point, the Controller through some protocol can query the MA relative to the range that can be supported for each parameter in the Measurement Method of interest.=C2=A0

Because I am of the opinion that if MAs are to be implementable in devices that could include modems and residential gateways at the customer premises, cost becomes an issue.=C2=A0 In other words, I want the ability to add MA functionality to a modem or residential gateway to be a simple as possible, and the cost to be as low as possible.=C2=A0=C2=A0 So my thoughts will generally come from the persp= ective of minimizing protocol complexity.=C2=A0 Consequently, I had the list reporting approach upon registration in mind.=C2=A0 But now that you mention it, I can see how the LMAP framework can be interpreted to allow an MA to report that it can support a given Measurement Method even though it may not support the full range of valid values for each parameter.=C2=A0

That said, I can back off of my original statement of, "If the MA cannot support the full range of values, then the MA cannot claim to support the Measurement Method."=C2=A0 However, I would like to se= e some text in LMAP to elaborate on this topic.=C2=A0 I think this discussion also highlights the need for the protocol work to be done so that LMAP can point to it.
Charles



On 6/6/2014 2:20 PM, Greg Mirsky wrote:
=20
Hi Charles,
though discussion of what level of support of particular Measurement Method by an MA is acceptable seems premature and more appropriate to discussion of Control Protocol, I'd like to note that I cannot agree with your suggestion: "If the MA
cannot support the full range of values, then the MA cannot claim to support the Measurement Method."

Regards,
Greg




On Fri, Jun 6, 2014 at 7:54 AM, Charles Cook <charles.cook2@centurylink.com> wrote:
I agree with Barbara that we need to ensure that we have a clear
distinction between Measurement Method and Measurement Task.
My view of the Measurement Method is that the Measurement Method is what
is included in a Registry somewhere. =C2=A0The Measurement Meth= od is
essentially a template of a particular type of measurement with a set of
parameters that can be specified. =C2=A0A Measurement Task is a= n instance of
the Measurement Method where specific values have been specified for
each of the parameters in the Measurement Method. =C2=A0Those that are closer
to defining what a Measurement Method is and what a Measurement Task is
can hopefully confirm or clarify as appropriate.

An MA will need to be able to report to the Controller that it is
registered to what capabilities it has relative to what Measurement
Methods it can support. =C2=A0If a MA indicates it can support = a particular
Measurement Method, that implies the MA can support the full range of
values that can be assigned by the Controller to the parameters of the
Measurement Method in the creation of a Measurement Task. =C2=A0If the MA
cannot support the full range of values, then the MA cannot claim to
support the Measurement Method.

Even though it may not be within the scope of LMAP, I believe it would
be helpful if someone can propose a sample Measurement Method with all
its parameters as an example that we can use to validate whether the
LMAP framework is adequately complete. =C2=A0Maybe a sample Measurement
Method can be derived from work in ippm (I have not participated in ippm
so I don't know if this can be done).

A sample Measurement Method to exercise the LMAP framework should help
us to:
- determine whether all the bases have been covered in terms of what
functions the LMAP framework needs to support to ensure the execution of
meaningful Measurement Tasks, and
- ensure that a Measurement Method is sufficiently specified to enable
results from multiple executions of a Measurement Task generated from
the Measurement Method to be compared and analyzed in post processing in
a meaningful way.

Charles




On 6/6/2014 7:48 AM, STARK, BARBARA H wrote:
> Now that it appears we may have resolved the LMAP active/passive debates (by getting rid of the words) and ambiguity around "which tasks get suppressed by default", maybe we could agree on what Measurement Method and Measurement Task are?
>
> I'd like to propose:
> =C2=A0 =C2=A0Measurement Method: The process for asses= sing the value of a Metric;
> =C2=A0 =C2=A0the process of measuring some performance= or reliability parameter
> =C2=A0 =C2=A0associated with the transfer of traffic; = where this process involves multiple MAs or MPs, each may perform different roles.
>
> =C2=A0 =C2=A0Measurement Task: The act that consists o= f the single operation of
> =C2=A0 =C2=A0a Measurement Method role at a particular= time and with all its Input
> =C2=A0 =C2=A0Parameters set to specific values.
>
> Measurement Method role is not a defined term, but can be used to express the capability implemented within a MA (or MP) that allows it to participate in a Measurement Method. I see that various ippm RFCs use the word "role" in this way, including OWAMP and TWAM= P.
>
> If there is a need to talk about an instance of executing a Measurement Method, this could be called a Measurement Method instance. Again, without definition as a formal term.
>
> There exist several instances of "Measurement Method" that would need to become "Measurement Me= thod role". For example:
> =C2=A0 =C2=A0"A Measurement Task is a specific in= stantiation of a Measurement
> =C2=A0 =C2=A0Method role."
>
> =C2=A0 =C2=A0Capabilities: Information about the perfo= rmance measurement
> =C2=A0 =C2=A0capabilities of the MA, in particular the Measurement Method roles that it
> =C2=A0 =C2=A0can perform, and the device hosting the M= A, for example its interface
> =C2=A0 =C2=A0type and speed, but not dynamic informati= on.
>
> "the Measurement Method roles that the MA support= s"
>
> But most discussion of Measurement Method in framework is of the Measurement Method and not the Measurement Method role.
>
> There is one instance where "Measurement Task capability" is used in the same sense as a Measurement Method role: "...Measurement Agents may come from
> =C2=A0 =C2=A0 =C2=A0 different vendors, be in wired an= d wireless networks, have
> =C2=A0 =C2=A0 =C2=A0 different Measurement Task capabi= lities and be on devices with
> =C2=A0 =C2=A0 =C2=A0 IPv4 or IPv6 addresses."
>
> I found one instance where I question the use of "Measurement Task" and wonder if it should be "Measurement Method":
> =C2=A0 =C2=A0"Some Measurement Tasks involve seve= ral MAs acting in a coordinated
> =C2=A0 =C2=A0fashion."
>
> In my scan of framework, I couldn't find a place where I thought Measurement Task was used to mean a Measurement Method instance.
> Barbara
>
> _______________________________________________
> lmap mailing list
> lma= p@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap

--

Charles Cook
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO =C2=A080221
Tel: =C2=A0303.992.8952 =C2=A0Fax: =C2=A0925.281.0662
charles.cook2@centurylink.com

_______________________________________________
lmap mailing list
lmap@iet= f.org
https://www.ietf.org/mailman/listinfo/lmap


--=20

Charles Cook=20
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.=
cook2@centurylink.com

--001a11c1da06e2d86e04fb3159c0-- From nobody Fri Jun 6 18:33: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 EBF6A1A027C for ; Fri, 6 Jun 2014 18:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_72=0.6, 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 sn17fjQeRdGk for ; Fri, 6 Jun 2014 18:33:17 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7707C1A02A9 for ; Fri, 6 Jun 2014 18:33:16 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id lf12so347216vcb.22 for ; Fri, 06 Jun 2014 18:33:08 -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=fioLnTDwdNH7b5bjJDdpeIdGN2pmWZ2qKYStKCbsAFY=; b=Gyk25PesDUbKFO2O7YdmZxpQqXSkp/uUFxNKLBnxNOcu12SEunOgC7f2phjTmq2uli aXWKBWLtKlbmexj4aK+hcv7yvTUKt0JxkylWCBx6GwedjXVjFdW8cpy+gdZIryXqSx54 61z5ULIiknZt0LDlDERxy7Ak1Dv07d2Koq6L06tb7LRzAaB0KrVxBKySd8r6TxRuGvgR fsWX3aN2TJrXpHOmo/uJ448VeNSiozKDN+W5eH99uzS+hN/g4Fm2HPPXxDdJ4iMJIiQg hWlC/MT5di3YXTnngipFdup3V5Cq9/P169Qv0gebobDufsDWcWmoPOZB1EUc+FNTPeAq XLdg== MIME-Version: 1.0 X-Received: by 10.53.12.229 with SMTP id et5mr8394887vdd.32.1402104787973; Fri, 06 Jun 2014 18:33:07 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 6 Jun 2014 18:33:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Jun 2014 18:33:07 -0700 Message-ID: From: Greg Mirsky To: "philip.eardley@bt.com" Content-Type: multipart/alternative; boundary=001a1133fa5ed33d2104fb34f515 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8wVMyyBSLGh6I817pX8CEtdGGdo Cc: "lmap@ietf.org" Subject: Re: [lmap] Proposed changes to draft-ietf-lmap-framework-05.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: Sat, 07 Jun 2014 01:33:20 -0000 --001a1133fa5ed33d2104fb34f515 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, I'd add Configuration protocol (Section 5.2) to the list of issues to be addressed based on comments to -05 version. Regards, Greg On Fri, Jun 6, 2014 at 1:11 AM, wrote: > Just to highlight the proposed changes before I implement them:- > > > * a "suppression flag" > a Boolean true/false flag is all that is required =E2=80=93 to the Measur= ement > Task Configuration indicating whether that Task is to be suppressed by > default (in other words, if the Controller sends a suppression message > without specifying particular Tasks to be suppressed, then the MA would > check the Boolean flag for each Task) > > * remove the definition of Active and Passive > > please shout if you're unhappy with these changes > > thanks > phil > > ------------------------------ > *From:* lmap [lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com [ > philip.eardley@bt.com] > *Sent:* 05 June 2014 10:13 > *To:* KEN.KO@adtran.com; gregimirsky@gmail.com > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt > > i think this is a very good suggestion. i agree this is the right way > of separating policy and protocol > > as a side benefit, we can then drop the active vs passive distinction > (and terminology) (and do some slight rephrasing in the privacy section, > which is the main place that uses the terms) > > thanks > phil > > ------------------------------ > *From:* KEN KO [KEN.KO@adtran.com] > *Sent:* 05 June 2014 00:03 > *To:* Greg Mirsky; Eardley,PL,Philip,TUB8 R > *Cc:* lmap@ietf.org > *Subject:* RE: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt > > As I read this email thread which is similar to earlier ones discussing > active vs. passive, I keep thinking about the only place the distinction = is > being used in the lmap framework, which is for suppression. And, I keep > thinking that we are creating a distinction the details of which we canno= t > agree on, and that different test system operators intend to use in > different ways. And this leads me to think that there is a better way to > provide the agreed suppression behavior while allowing test system > operators to modify it as they wish. > > > > Default suppression behavior, as specified in framework-05: > > > > =E2=80=9CSuppression means that the MA does not begin any new > > Active Measurement Task. The impact on other Measurement Tasks is > > not defined by LMAP; since they do not involve the MA creating any > > Active Measurement Traffic there is no need to suppress them, however > > it may be simpler for an implementation to do so.=E2=80=9D > > > > We have arrived at this point because stakeholders could not agree on how > to treat Passive Tasks. As a result, some operators may suppress Passive > Tasks by default and others may let them continue, with variations betwee= n > those two extremes. And yet, since we are still debating where to draw th= e > line between Active and Passive, the matter is not settled. > > > > There is a better way. Simply add a field =E2=80=93 a Boolean true/false = flag is > all that is required =E2=80=93 to the Measurement Task Configuration indi= cating > whether that Task is to be suppressed by default. It shortcuts the Active > Passive arguments (at least, in lmap) and gives operators complete freedo= m > over default suppression behavior. > > > > The description of a Measurement Method in a registry could contain a > recommended value for the flag. However, operators would be free to use > that value or override it in their deployments. > > > > Comments? > > > > Ken > > > > > > *From:* lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Wednesday, June 04, 2014 10:40 AM > *To:* philip.eardley@bt.com > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] Follow-up on recent discussion about > draft-ietf-lmap-framework-05.txt > > > > Hi Phil, > > thank you for your prompt response to my comments. > > if I compare common interpretations of "observe" and "collect": > ob=C2=B7serve* verb* \=C9=99b-=CB=88z=C9=99rv\ > > : to watch and sometimes also listen to (someone or something) carefully > > : to see and notice (someone or something) > > : to make a comment about something you notice > > vs. > col=C2=B7lect* verb* \k=C9=99-=CB=88lekt\ > > : to get (things) from different places and bring them together > > : to get (one or more things) from a place > > : to get (similar things) and bring them together as a hobby > > the latter seems as more suitable in characterization of role of MA(s) in > executing Passive Measurement methods. > > RE: Measurement Domain. Given earlier discussion and suggestion to take > holistic approach to MA/MP role, I believe we are at the point where > discussion of Measurement Domain's definition and use is timely and > appropriate. > > Regards, > > Greg > > > > On Wed, Jun 4, 2014 at 8:34 AM, wrote: > > > > Proposal:- > > In the Intro, add to the paragraph about Active & Passive Tasks: > > There may also be Measurement Tasks that are intermediate between Passive > and Active ones; consideration is outside the initial LMAP work scope. > > > > In terminology, tweak the definitions:- > > Passive Measurement Task: A Measurement Task in which a Measurement Agent > observes existing traffic but does not inject Active Measurement Traffic. > > GIM>> I think that "observes" is not the same as "collect information > off". Can it be "... in which a Measurement Agent collects information of= f > existing traffic ..."? I think that a Measurement Agent may coordinate it= s > actions in performing Passive Measurement Task with other Measurement > Agents/Peers. More on it below. > > > > [phil] I don't really understand what difference you're getting at - what > meaning do you want to convey with "collect information" that differs fro= m > "observes"? > > > > Active Measurement Task: A Measurement Task in which a Measurement Agent > sends Active Measurement Traffic to, or receives it from, one or more oth= er > Measurement Agents or Measurement Peers, and perhaps coordinates with the= m > using protocols outside the initial LMAP work scope > > GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And > I'd like to discuss new Measurement Domain object defined as: > > The community of Measurement Agents and Measurement Peers that > cooperate in performing a Measurement Task, whether Active or Passive, > present a Measurement Domain. Coordination protocol(s) used within > Measurement Domain are outside of the initial LMAP work scope. > > Then in definitions of Active/Passive Measurement Task in the LMAP > Framework we can use the Measurement Domain like: > Passive Measurement Task: A Measurement Task in which a Measurement Agent > collects information off existing traffic within its Measurement Domain. > > > > [phil] yes, Active Measurement Traffic is what you could call test traffi= c > ["Active Measurement Traffic: the packet(s) generated in order to execute > an Active Measurement Task."] > > > > [phil] re measurement domain - i can see this may be a useful concept, bu= t > i don't think we've needed this term yet in lmap. given how tricky agreei= ng > terminology is, can we delay defining this term until we're sure we need = it. > > > > thanks > > phil > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --001a1133fa5ed33d2104fb34f515 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
I'd add Configuration= protocol (Section 5.2) to the list of issues to be addressed based on comm= ents to -05 version.

Regards,
Greg


On Fri, Jun 6, 2014 at 1:11 AM, <p= hilip.eardley@bt.com> wrote:
Just to highlight the proposed changes before I implement them:-
=C2=A0
=C2=A0
* a "suppression flag"
a Boolean true/fal= se flag is all that is required =E2=80=93 to the Measurement Task Configura= tion indicating whether that Task is to be suppressed by default (in other = words, if the Controller sends a suppression message without specifying particular Tasks to be suppressed, then the MA would ch= eck the Boolean flag for each Task)
=C2=A0
* remove the defin= ition of Active and Passive
=C2=A0
please shout if yo= u're unhappy with these changes
=C2=A0
thanks
phil
=C2=A0
From: lmap [lmap-bounces@ietf.org] On Be= half Of philip.e= ardley@bt.com [philip.eardley@bt.com]
Sent: 05 June 2014 10:13
To: KEN.KO@ad= tran.com; gr= egimirsky@gmail.com
Cc: lmap@ietf.org=
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-= lmap-framework-05.txt

i think this is a very good suggestion. i agree this is the right way = of separating policy and protocol
=C2=A0
as a side benefit, = we can then drop the active vs passive distinction (and terminology) (and d= o some slight rephrasing in the privacy section, which is the main place th= at uses the terms)
=C2=A0
thanks
phil
=C2=A0
From: KEN KO [KEN.KO@adtran.com]
Sent: 05 June 2014 00:03
To: Greg Mirsky; Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org=
Subject: RE: [lmap] Follow-up on recent discussion about draft-ietf-= lmap-framework-05.txt

As I read this email thread whi= ch is similar to earlier ones discussing active vs. passive, I keep thinkin= g about the only place the distinction is being used in the lmap framework, which is for suppression. And, I keep thinking= that we are creating a distinction the details of which we cannot agree on= , and that different test system operators =C2=A0intend to use in different= ways. And this leads me to think that there is a better way to provide the agreed suppression behavior while all= owing test system operators to modify it as they wish.

=C2=A0

Default suppression behavior, a= s specified in framework-05:

=C2=A0

=E2=80=9CSuppression means that= the MA does not begin any new

Active Measurement Task. The im= pact on other Measurement Tasks is

not defined by LMAP; since they= do not involve the MA creating any

Active Measurement Traffic ther= e is no need to suppress them, however

it may be simpler for an implem= entation to do so.=E2=80=9D

=C2=A0

We have arrived at this point b= ecause stakeholders could not agree on how to treat Passive Tasks. As a res= ult, some operators may suppress Passive Tasks by default and others may let them continue, with variations between those= two extremes. And yet, since we are still debating where to draw the line = between Active and Passive, the matter is not settled.

=C2=A0

There is a better way. Simply a= dd a field =E2=80=93 a Boolean true/false flag is all that is required =E2= =80=93 to the Measurement Task Configuration indicating whether that Task is to be suppressed by default. It shortcuts the Active Passive = arguments (at least, in lmap) and gives operators complete freedom over def= ault suppression behavior.

=C2=A0

The description of a Measuremen= t Method in a registry could contain a recommended value for the flag. Howe= ver, operators would be free to use that value or override it in their deployments.

=C2=A0

Comments?

=C2=A0

Ken

=C2=A0

=C2=A0

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Wednesday, June 04, 2014 10:40 AM
To: phili= p.eardley@bt.com
Cc: lmap@ietf.org=
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-= lmap-framework-05.txt

=C2=A0

Hi Phil,

thank you for your promp= t response to my comments.

if I compare common inte= rpretations of "observe" and "collect":

ob=C2=B7= serve verb \=C9=99b-=CB=88z=C9=99rv\

: to watch and sometimes also listen to (som= eone or something) carefully

: to see and notice (someone or something)

: to make a comment abou= t something you notice

vs.

col=C2= =B7lect verb \k=C9=99-=CB=88lekt\

: to get (things) from different places and = bring them together

: to get (one or more things) from a place

: to get (similar things= ) and bring them together as a hobby

the latter seems as more= suitable in characterization of role of MA(s) in executing Passive Measure= ment methods.

RE: Measurement Domain. Given earlier discussion and suggestion to take hol= istic approach to MA/MP role, I believe we are at the point where discussio= n of Measurement Domain's definition and use is timely and appropriate.=

Regards,

Greg

=C2=A0

On Wed, Jun 4, 2014 at 8= :34 AM, <phil= ip.eardley@bt.com> wrote:

=C2=A0

Proposal:-<= /span>

In the Intr= o, add to the paragraph about Active & Passive Tasks:

There may a= lso be Measurement Tasks that are intermediate between Passive and Active o= nes; consideration is outside the initial LMAP work scope.

=C2= =A0

In terminol= ogy, tweak the definitions:-

Passive Mea= surement Task: A Measurement Task in which a Measurement Agent observes exi= sting traffic but does not inject Active Measurement Traffic.

GIM>>= I think that "observes" is not the same as "collect informa= tion off". Can it be "... in which a Measurement Agent collects i= nformation off existing traffic ..."? I think that a Measurement Agent may coord= inate its actions in performing Passive Measurement Task with other Measure= ment Agents/Peers. More on it below.

=C2=A0

[phil] I don't really understand what difference you're = getting at - what meaning do you want to convey with "collect information" that differs from "observes"?

=C2= =A0

Active Meas= urement Task: A Measurement Task in which a Measurement Agent sends Active = Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordin= ates with them using protocols outside the initial LMAP work scope

GIM>>= Is "Active Measurement Traffic" the same as "Test Traffic&q= uot;? And I'd like to discuss new Measurement Domain object defined as:= =C2=A0

The communi= ty of Measurement Agents and Measurement Peers that cooperate in performing= a Measurement Task, whether Active or Passive, present a Measurement Domain. Coordination protocol(s) used within Measure= ment Domain are outside of the initial LMAP work scope.

Then i= n definitions of Active/Passive Measurement Task in the LMAP Framework we c= an use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent c= ollects information off existing traffic within its Measurement Domain.

=C2=A0

[phil]= yes, Active Measurement Traffic is what you could call test traffic ["= ;Active Measurement Traffic: the packet(s) generated in order to=C2=A0execute an Active Measurement Task."]

=C2=A0

[phil]= re measurement domain - i can see this may be a useful concept, but i don&= #39;t think we've needed this term yet in lmap. given how tricky agreeing terminology is, can we delay defining this term until = we're sure we need it.

=C2=A0

thanks=

phil

=C2=A0


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


--001a1133fa5ed33d2104fb34f515-- From nobody Sat Jun 7 02:54: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 D08551A0332 for ; Sat, 7 Jun 2014 02:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 DWrJD1vE6c0l for ; Sat, 7 Jun 2014 02:54:54 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9081A0339 for ; Sat, 7 Jun 2014 02:54:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8OAMrgklPGmAcV/2dsb2JhbABZgkYjJFJZqn+DB4x8iQ0BgQMWdYQFAQEDEhteAQwJFVYmAQQbGoggAQyeZIRcqWEXhV2FcQGCaYNjgRYEm1+FXYwlgXyBQIIv X-IronPort-AV: E=Sophos; i="4.98,994,1392181200"; d="scan'208,217"; a="69553900" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Jun 2014 05:54:44 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 07 Jun 2014 05:36:34 -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; Sat, 7 Jun 2014 05:54:42 -0400 From: "Romascanu, Dan (Dan)" To: "''" Thread-Topic: http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ - ready for IESG submission? Thread-Index: Ac+CNoAAct74rh0aR0OGtNG686OMXQ== Date: Sat, 7 Jun 2014 09:54:41 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C807626@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_9904FB1B0159DA42B0B887B7FA8119CA5C807626AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5vji9fwChi9aQG967xU6DDCTe-4 Subject: [lmap] http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ - ready for IESG submission? 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: Sat, 07 Jun 2014 09:54:56 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C807626AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The authors of http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ u= pdated the I-D after the WGLC addressing all comments. The chair believe th= at the I-D is ready for submission to the IESG for consideration as informa= tional RFC. If anybody thinks differently, please speak up in the coming da= ys. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C807626AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The authors of http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/ updated the = I-D after the WGLC addressing all comments. The chair believe that the I-D = is ready for submission to the IESG for consideration as informational RFC.= If anybody thinks differently, please speak up in the coming days.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C807626AZFFEXMB04globa_-- From nobody Sat Jun 7 03:05: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 9BB781A0338 for ; Sat, 7 Jun 2014 03:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 ycXtcQWkO054 for ; Sat, 7 Jun 2014 03:05:41 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B092C1A0332 for ; Sat, 7 Jun 2014 03:05:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoLAG/iklOHCzIm/2dsb2JhbABZgkYjJFJZqnkGmRABgQMWdYQFAQEDEhteAQwJFVYmAQQbGoggAZ5yhFypXxeFXYhbg2OBFgShPIwlgzyCLw X-IronPort-AV: E=Sophos; i="4.98,994,1392181200"; d="scan'208,217"; a="59688363" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jun 2014 06:05:31 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 07 Jun 2014 06:03:16 -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; Sat, 7 Jun 2014 06:05:28 -0400 From: "Romascanu, Dan (Dan)" To: "''" Thread-Topic: LMAP protocol contributions Thread-Index: Ac+CN/8RcjXHoXqGTUKJ05mYtqsyVQ== Date: Sat, 7 Jun 2014 10:05:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C80764E@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_9904FB1B0159DA42B0B887B7FA8119CA5C80764EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/0GHd7VZ8c3UqM9hSm0vbyRizfWc Subject: [lmap] LMAP protocol contributions 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: Sat, 07 Jun 2014 10:05:42 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C80764EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, With the progress being made with the use cases and framework documents whi= ch we expect to be submitted soon to the IESG, we (chairs) believe that it'= s a good time to start discussing submissions for the LMAP protocols. We ha= d until now only one such submission (draft-bagnulo-...) which expired and = we expect to be updated and re-submitted. It would be good to know earlier = if people plan other submissions in this year, and an estimation about when= they will show up (especially if time will be required to discuss these at= IETF-90). Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C80764EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

With the progress being made with the use cases and = framework documents which we expect to be submitted soon to the IESG, we (c= hairs) believe that it’s a good time to start discussing submissions = for the LMAP protocols. We had until now only one such submission (draft-bagnulo-…) which expired and we expe= ct to be updated and re-submitted. It would be good to know earlier if peop= le plan other submissions in this year, and an estimation about when they w= ill show up (especially if time will be required to discuss these at IETF-90).

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C80764EAZFFEXMB04globa_-- From nobody Sat Jun 7 06:53: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 1B7081A0091 for ; Sat, 7 Jun 2014 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Or8-mqqURVmC for ; Sat, 7 Jun 2014 06:53:03 -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 C447A1A006D for ; Sat, 7 Jun 2014 06:53:03 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 98B0A1201B5; Sat, 7 Jun 2014 09:55:30 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id A81D6E037D; Sat, 7 Jun 2014 09:52:49 -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; Sat, 7 Jun 2014 09:52:49 -0400 From: "MORTON, ALFRED C (AL)" To: "STARK, BARBARA H" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Date: Sat, 7 Jun 2014 09:52:48 -0400 Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAKrjAAAAPzgiAAItEZ+w== Message-ID: <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.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/5laE04e0FsxPfHU8sbmL3EXbayE Subject: Re: [lmap] Measurement Methods and Tasks 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: Sat, 07 Jun 2014 13:53:07 -0000 Sorry to join in late, flying all day Friday... I tend to agree that there are example scenarios where the=20 "role" communicated to an MA resolves ambiguity. I imagine a task where the role is TWAMP server and responder, and the task is to open the well-know ports and listen for duration X, etc. Of course, this MA and device may take on different roles in other tasks if equipped to do so, and "role" specification resolves that ambiguity. OTOH, another MA would be assigned to fill the roles of=20 TWAMP Control-Client and Sender, and to initiate sessions with the responder tasked above. Without roles, you could have two responders listening for each other. It may help to consider that the MA will likely coordinate with the=20 local measurement control in its device, and measurement control subsequently coordinates with local measurement functions to=20 measure the registered metrics (and that's where the registry has relevance, after roles are established for the measurement protocol). What I wonder about at the moment is how the role might be expressed in general, yet unambiguous to any measurement protocol available at the MA= , or whether the Controller would need to know the measurement protocols available, specifying the one to use and the protocol-specific role. Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Friday, June 06, 2014 1:21 PM To: charles.cook2@centurylink.com; lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Hi Charles, I provided a UDP Echo example a week ago. Here is my breakdown of that exam= ple: Measurement Method =3D UDP Echo role 1 =3D UDP Echo Server inputs =3D a port to listen on and a source IP address (MA1 will only = respond to UDP packets from this source IP address) outputs =3D packets and bytes received, packets and bytes sent role 2 =3D UDP Echo Client inputs =3D packet size, destination IP address, time interval between = UDP packets, and number of UDP packets outputs =3D average/max elapsed time between a sent UDP packet and the= response, jitter, etc. If a MA reported its capability to the Controller as "UDP Echo", this would= be ambiguous, because it would mean the MA supported client, server, or bo= th and the Controller has no way of knowing which. If the registry simply listed UDP Echo input parameters as listening port, = source IP address, packet size, destination IP address, time interval betwe= en UDP packets, and number of UDP packets, then the Controller (who has no = information as to which inputs belong to which role or even which role the = MA supports) would need to send values for all of these input parameters to= the MA and hope the MA can pick out the right ones? The Controller would h= ave to tell the MA which role it needed the MA to perform and hope the MA i= s capable of that particular role. I propose that the MA reported capabilities indicate the supported role(s) = of a particular method, and that the registry entries indicate inputs and o= utputs per role. An MA does *not* support UDP Echo. It supports UDP Echo Client or UDP Echo = Server. If both, then the MA reports them to the Controller as separate cap= abilities. Barbara > -----Original Message----- > From: Charles Cook [mailto:charles.cook2@centurylink.com] > Sent: Friday, June 06, 2014 10:54 AM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks > > I agree with Barbara that we need to ensure that we have a clear distinct= ion > between Measurement Method and Measurement Task. > > My view of the Measurement Method is that the Measurement Method is > what is included in a Registry somewhere. The Measurement Method is > essentially a template of a particular type of measurement with a set of > parameters that can be specified. A Measurement Task is an instance of t= he > Measurement Method where specific values have been specified for each of > the parameters in the Measurement Method. Those that are closer to > defining what a Measurement Method is and what a Measurement Task is > can hopefully confirm or clarify as appropriate. > > An MA will need to be able to report to the Controller that it is registe= red to > what capabilities it has relative to what Measurement Methods it can > support. If a MA indicates it can support a particular Measurement Metho= d, > that implies the MA can support the full range of values that can be assi= gned > by the Controller to the parameters of the Measurement Method in the > creation of a Measurement Task. If the MA cannot support the full range = of > values, then the MA cannot claim to support the Measurement Method. > > Even though it may not be within the scope of LMAP, I believe it would be > helpful if someone can propose a sample Measurement Method with all its > parameters as an example that we can use to validate whether the LMAP > framework is adequately complete. Maybe a sample Measurement Method > can be derived from work in ippm (I have not participated in ippm so I do= n't > know if this can be done). > > A sample Measurement Method to exercise the LMAP framework should > help us to: > - determine whether all the bases have been covered in terms of what > functions the LMAP framework needs to support to ensure the execution of > meaningful Measurement Tasks, and > - ensure that a Measurement Method is sufficiently specified to enable > results from multiple executions of a Measurement Task generated from the > Measurement Method to be compared and analyzed in post processing in a > meaningful way. > > Charles > > > > > On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > > Now that it appears we may have resolved the LMAP active/passive > debates (by getting rid of the words) and ambiguity around "which tasks g= et > suppressed by default", maybe we could agree on what Measurement > Method and Measurement Task are? > > > > I'd like to propose: > > Measurement Method: The process for assessing the value of a Metric; > > the process of measuring some performance or reliability parameter > > associated with the transfer of traffic; where this process involves > multiple MAs or MPs, each may perform different roles. > > > > Measurement Task: The act that consists of the single operation of > > a Measurement Method role at a particular time and with all its Inpu= t > > Parameters set to specific values. > > > > Measurement Method role is not a defined term, but can be used to > express the capability implemented within a MA (or MP) that allows it to > participate in a Measurement Method. I see that various ippm RFCs use the > word "role" in this way, including OWAMP and TWAMP. > > > > If there is a need to talk about an instance of executing a Measurement > Method, this could be called a Measurement Method instance. Again, > without definition as a formal term. > > > > There exist several instances of "Measurement Method" that would need > to become "Measurement Method role". For example: > > "A Measurement Task is a specific instantiation of a Measurement > > Method role." > > > > Capabilities: Information about the performance measurement > > capabilities of the MA, in particular the Measurement Method roles t= hat it > > can perform, and the device hosting the MA, for example its interfac= e > > type and speed, but not dynamic information. > > > > "the Measurement Method roles that the MA supports" > > > > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. > > > > There is one instance where "Measurement Task capability" is used in th= e > same sense as a Measurement Method role: "...Measurement Agents may > come from > > different vendors, be in wired and wireless networks, have > > different Measurement Task capabilities and be on devices with > > IPv4 or IPv6 addresses." > > > > I found one instance where I question the use of "Measurement Task" and > wonder if it should be "Measurement Method": > > "Some Measurement Tasks involve several MAs acting in a coordinated > > fashion." > > > > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > > Barbara > > > > _______________________________________________ > > 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 From nobody Mon Jun 9 05:36: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 CB1EC1A011C for ; Mon, 9 Jun 2014 05:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 F1WsRXDxO2GH for ; Mon, 9 Jun 2014 05:36:26 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5713D1A0117 for ; Mon, 9 Jun 2014 05:36:26 -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 a4aa5935.2b492e02f940.11325573.00-2431.28488905.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jun 2014 12:36:26 +0000 (UTC) X-MXL-Hash: 5395aa4a2889f781-1e08c74fe721e8c099d22111b79d6d0e97876143 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 84aa5935.0.11325565.00-2353.28488868.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jun 2014 12:36:25 +0000 (UTC) X-MXL-Hash: 5395aa495bca5096-fd938b2cd7df75b232d20a027274d78d9543365a 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 s59CaNHs024728; Mon, 9 Jun 2014 08:36:23 -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 s59CaF1d024633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 08:36:16 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 9 Jun 2014 12:35:53 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 08:35:53 -0400 From: "STARK, BARBARA H" To: "marc.ibrahim" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAKrjAAAAPzgiAABqmSAAB9m1dQ Date: Mon, 9 Jun 2014 12:35:53 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE77DE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com> <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <20140606184942.M27222@mail.usj.edu.lb> In-Reply-To: <20140606184942.M27222@mail.usj.edu.lb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.174] 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=HL104PRv c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=mUbaKL4_SQQA:10 a=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=yPQ5IXaLyuFnBEzL4toA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QBuFeVp88v4dqiuOzSIdh05hB-s Subject: Re: [lmap] Measurement Methods and Tasks 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, 09 Jun 2014 12:36:27 -0000 > Now let me take the same UDP echo example with two "UDP echo clients" > MAs, MA1 and MA2 simultaneously executing a UDP echo measurement > with the same "UDP echo server" MA0. >=20 >=20 > MA1 <--- UDP echo ------> | MA0 | <------ UDP echo ---------> MA 2 >=20 > Here, we have two instances of the same measurement method. > In each instance, the MA0 is playing the server role. >=20 > From the following, what is the correct answer: >=20 > a- MA0 is executing two different tasks. >=20 > b- MA0 is executing only one global server task. The task consists in sta= rting > the UDP- > echo server according to the controller scheduler. >=20 > c- MA0 is executing two instances of the same task. >=20 >=20 > Answer a is not practical since MA0 has to have a different task for each > possible > client. >=20 > Answer b is the most suitable with the current lmap model, since a task i= s > instructed by > the controller and started according to some schedule. But this is not > compatible with > my understanding of "Barbara's tasks" (Here, it is kind of a Meta-task) >=20 > Answer c, means that MA0 has only one task that has been started twice by > MA1 and MA2. > This means that servers tasks cannot be scheduled like client tasks and n= eed > specific > treatment. Since Source IP Address is one of the task/role configured inputs, and MA1 = and MA2 presumably have different source IP addresses, I think (a) is actua= lly the right answer in a UDP Echo context. Note that the UDP Echo Server i= s expected to be on a CPE device, and the UDP Echo Client is expected to be= somewhere in the network. UDP Echo Server is not something left continuous= ly running that any old UDP Echo Client can test against. This is a tightly= coordinated test. But if we generalize this question, it's certainly possible to envision hol= istic measurement techniques where (b) would be the right answer -- for exa= mple something like an ICMP Echo (ping) server that is continuously running= (i.e., the schedule has no end time) and tracks and reports statistics rel= ated to its ICMP Echo server activities. But where (b) is the right answer,= I wouldn't expect there to be coordination between the Echo Server and= Echo Client Measurement Tasks. They would likely be communicating with= different Controllers. In fact the Echo Server might even be in a MP a= nd not MA. But I don't think it follows that this server activity isn't con= sistent with the way I conceptualize a Measurement Task. I think it would s= till be possible to configure this continuously running server as a single = Measurement Task. There just wouldn't be any correlation between the Client= and Server Measurement Tasks, and the role entries in the Registry would b= e very different. I don't think I understand (c). Barbara From nobody Mon Jun 9 09:42:41 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 AEE3F1A01EF for ; Mon, 9 Jun 2014 09:42:39 -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 2lTGEO1IAWVW for ; Mon, 9 Jun 2014 09:42:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F441A0096 for ; Mon, 9 Jun 2014 09:42:36 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 17:42:41 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 9 Jun 2014 17:42:34 +0100 From: To: Date: Mon, 9 Jun 2014 17:42:33 +0100 Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWw== 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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3315EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/N0lNmXhQz0M3nhZplsAwYpfHBg8 Subject: [lmap] Suppression in 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: Mon, 09 Jun 2014 16:42:39 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3315EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3315EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So we have agreed to modi= fy suppression so the default behaviour is that tasks have a Boolean flag w= hich indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag= to be when we have the more complex, optional Suppress message? (it lists = specific Tasks or Schedules for suppression.)  

<= p class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15=

 

Treating the Boolean flag as meaning “do-not-suppress this Measur= ement Task”, my proposal is to basically keep the current text unalte= red:

      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   

<< Optionally the Suppression info=
rmation may

   include:

 

   o  a set of M= easurement Tasks to suppress; the others are not

&nb= sp;     suppressed.  For example, this could be us= eful if a particular

      = Measurement Task is overloading a Measurement Peer.

=  

  &= nbsp;   suppressed.  For example, suppose the measurement sy= stem has

      defined two = Schedules, one with the most critical Measurement

=       Tasks and the other with less critical ones = that create a lot of

      = Active Measurement Traffic, then it may only want to suppress the

      second.

<= p class=3DMsoNormal style=3D'page-break-before:always'> 

   o  a start time, at which = suppression begins

 

&nb= sp;  o  an end time, at which suppression ends<= /p>

 

   o  a demand that the M= A ends its on-going Active Measurement Task(s)

 = ;     (and deletes the associated partial Measurement R= esult(s)).

>> 

 

In other words, if= the Controller says “Suppress Task #213” then the MA checks th= e do-not-suppress flag for Task #213 and either throws an error or doesn= 217;t start this Task. Similarly, if the Controller says “Suppress Sc= hedule #49”, then the MA checks the do-not-suppress flag for Tasks in= this schedule and either throws an error or doesn’t start any new Ta= sks in this schedule.

 

I’ll tweak the text to say this (as well as remov= ing the refs to Active).

I’ll also m= ake clear that the Controller sets the do-not-suppress flag for a Task (it = isn’t something that the MA decides about).

 

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3315EMV67UKRDdoma_-- From nobody Mon Jun 9 09:49:41 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 35F551A01EF for ; Mon, 9 Jun 2014 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 2aec2Z52pLWZ for ; Mon, 9 Jun 2014 09:49:35 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479351A01EA for ; Mon, 9 Jun 2014 09:49:35 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c11o141.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id f95e5935.2aba58853940.9042.00-507.24598.p01c11o141.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 10:49:35 -0600 (MDT) X-MXL-Hash: 5395e59f7c31bbb8-a33d74b6dd46a776715e60e9f4b9306f852fd628 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c11o141.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 785e5935.0.8733.00-340.23748.p01c11o141.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 10:49:20 -0600 (MDT) X-MXL-Hash: 5395e5905c29fe59-29de90af38bf239d9714b1ed6ab0e81637df6b5e Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 11:49:11 -0500 From: KEN KO To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dA Date: Mon, 9 Jun 2014 16:49:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FD60exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=BpsTwOn5 c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=qZHQZMT3apYA:10 a=eQt] X-AnalysisOut: [CghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8] X-AnalysisOut: [ a=_SnfkM3z8S6rswNcQqEA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=W1qU_X6G3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [KEsDroWL6r_zmxUGFQYA:9 a=jj4ew2-RQZBUuUMz:21 a=gKO2Hq4RSVk] X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060920); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WgXFi18STl5j1sB6f8J7iZZVmuA Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 16:49:38 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FD60exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FD60exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would think that inf= ormation in the optional Suppress fields would override the default behavio= r flag. That is, if the do-not-suppress flag was set for a given task, yet = a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be s= uppressed and no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that t= asks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the mo= re complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measureme= nt Task”, my proposal is to basically keep the current text unaltered= :

            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;          

<<<=
/span> Optionally the Suppression information may<=
o:p>

=    include:

=  

=    o  a set of Measurement = Tasks to suppress; the others are not

=       suppressed.=   For example, this could be useful if a particular<= /p>

=       Measurement= Task is overloading a Measurement Peer.

=  

=    o  a set of Measurement = Schedules to suppress; the others are not

=       suppressed.=   For example, suppose the measurement system has

=       defined two= Schedules, one with the most critical Measurement

=       Tasks and t= he other with less critical ones that create a lot of

=       Active Meas= urement Traffic, then it may only want to suppress the

=       second.

=  

=    o  a start time, at whic= h suppression begins

=  

=    o  an end time, at which= suppression ends

=  

=    o  a demand that the MA = ends its on-going Active Measurement Task(s)

=       (and delete= s the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” th= en the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Act= ive).

I’ll also make clear that the Controller sets the do-not-suppress fl= ag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil

--_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FD60exmb1corpadtran_-- From nobody Mon Jun 9 09:50: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 E50291A0271 for ; Mon, 9 Jun 2014 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-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 CY8XA_PkCBUR for ; Mon, 9 Jun 2014 09:50:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020F01A01EA for ; Mon, 9 Jun 2014 09:50:39 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 17:46:27 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 9 Jun 2014 17:50:38 +0100 From: To: , , , Date: Mon, 9 Jun 2014 17:50:36 +0100 Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAKrjAAAAPzgiAAItEZ+wBrmeNg Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.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/LOIW8xdwUrU8dZkakcOHM8PrxF0 Subject: Re: [lmap] Measurement Methods and Tasks 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, 09 Jun 2014 16:50:43 -0000 So in the framework we say << The Instruction defines information with the following aims ([I-D.ietf-lmap-information-model] defines the consequent list of information elements): o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. >> Should this bullet refer to Measurement Method or Measurement Method role? = Do we define a registry of Methods or Method roles? Either is possible. I'm not sure, but it's probably more consistent with ippm for it to be a re= gistry of Methods. So then the Method needs an Input Parameter (or some oth= er kind of configuration option) to choose between different roles (client,= server...) Thoughts? > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED C > (AL) > Sent: 07 June 2014 14:53 > To: STARK, BARBARA H; charles.cook2@centurylink.com; lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks >=20 > Sorry to join in late, flying all day Friday... >=20 > I tend to agree that there are example scenarios where the "role" > communicated to an MA resolves ambiguity. >=20 > I imagine a task where the role is TWAMP server and responder, and the > task is to open the well-know ports and listen for duration X, etc. > Of course, this MA and device may take on different roles in other > tasks if equipped to do so, and "role" specification resolves that > ambiguity. >=20 > OTOH, another MA would be assigned to fill the roles of TWAMP Control- > Client and Sender, and to initiate sessions with the responder tasked > above. Without roles, you could have two responders listening for each > other. >=20 > It may help to consider that the MA will likely coordinate with the > local measurement control in its device, and measurement control > subsequently coordinates with local measurement functions to measure > the registered metrics (and that's where the registry has relevance, > after roles are established for the measurement protocol). >=20 > What I wonder about at the moment is how the role might be expressed in > general, yet unambiguous to any measurement protocol available at the > MA, or whether the Controller would need to know the measurement > protocols available, specifying the one to use and the protocol- > specific role. >=20 > Al > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: Friday, June 06, 2014 1:21 PM > To: charles.cook2@centurylink.com; lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks >=20 > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more > information. >=20 > Hi Charles, > I provided a UDP Echo example a week ago. Here is my breakdown of that > example: > Measurement Method =3D UDP Echo > role 1 =3D UDP Echo Server > inputs =3D a port to listen on and a source IP address (MA1 will > only respond to UDP packets from this source IP address) > outputs =3D packets and bytes received, packets and bytes sent > role 2 =3D UDP Echo Client > inputs =3D packet size, destination IP address, time interval > between UDP packets, and number of UDP packets > outputs =3D average/max elapsed time between a sent UDP packet and > the response, jitter, etc. >=20 > If a MA reported its capability to the Controller as "UDP Echo", this > would be ambiguous, because it would mean the MA supported client, > server, or both and the Controller has no way of knowing which. >=20 > If the registry simply listed UDP Echo input parameters as listening > port, source IP address, packet size, destination IP address, time > interval between UDP packets, and number of UDP packets, then the > Controller (who has no information as to which inputs belong to which > role or even which role the MA supports) would need to send values for > all of these input parameters to the MA and hope the MA can pick out > the right ones? The Controller would have to tell the MA which role it > needed the MA to perform and hope the MA is capable of that particular > role. >=20 > I propose that the MA reported capabilities indicate the supported > role(s) of a particular method, and that the registry entries indicate > inputs and outputs per role. > An MA does *not* support UDP Echo. It supports UDP Echo Client or UDP > Echo Server. If both, then the MA reports them to the Controller as > separate capabilities. > Barbara >=20 > > -----Original Message----- > > From: Charles Cook [mailto:charles.cook2@centurylink.com] > > Sent: Friday, June 06, 2014 10:54 AM > > To: STARK, BARBARA H; lmap@ietf.org > > Subject: Re: [lmap] Measurement Methods and Tasks > > > > I agree with Barbara that we need to ensure that we have a clear > > distinction between Measurement Method and Measurement Task. > > > > My view of the Measurement Method is that the Measurement Method is > > what is included in a Registry somewhere. The Measurement Method is > > essentially a template of a particular type of measurement with a set > > of parameters that can be specified. A Measurement Task is an > > instance of the Measurement Method where specific values have been > > specified for each of the parameters in the Measurement Method. > Those > > that are closer to defining what a Measurement Method is and what a > > Measurement Task is can hopefully confirm or clarify as appropriate. > > > > An MA will need to be able to report to the Controller that it is > > registered to what capabilities it has relative to what Measurement > > Methods it can support. If a MA indicates it can support a > particular > > Measurement Method, that implies the MA can support the full range of > > values that can be assigned by the Controller to the parameters of > the > > Measurement Method in the creation of a Measurement Task. If the MA > > cannot support the full range of values, then the MA cannot claim to > support the Measurement Method. > > > > Even though it may not be within the scope of LMAP, I believe it > would > > be helpful if someone can propose a sample Measurement Method with > all > > its parameters as an example that we can use to validate whether the > > LMAP framework is adequately complete. Maybe a sample Measurement > > Method can be derived from work in ippm (I have not participated in > > ippm so I don't know if this can be done). > > > > A sample Measurement Method to exercise the LMAP framework should > help > > us to: > > - determine whether all the bases have been covered in terms of what > > functions the LMAP framework needs to support to ensure the execution > > of meaningful Measurement Tasks, and > > - ensure that a Measurement Method is sufficiently specified to > enable > > results from multiple executions of a Measurement Task generated from > > the Measurement Method to be compared and analyzed in post processing > > in a meaningful way. > > > > Charles > > > > > > > > > > On 6/6/2014 7:48 AM, STARK, BARBARA H wrote: > > > Now that it appears we may have resolved the LMAP active/passive > > debates (by getting rid of the words) and ambiguity around "which > > tasks get suppressed by default", maybe we could agree on what > > Measurement Method and Measurement Task are? > > > > > > I'd like to propose: > > > Measurement Method: The process for assessing the value of a > Metric; > > > the process of measuring some performance or reliability > parameter > > > associated with the transfer of traffic; where this process > > > involves > > multiple MAs or MPs, each may perform different roles. > > > > > > Measurement Task: The act that consists of the single operation > of > > > a Measurement Method role at a particular time and with all its > Input > > > Parameters set to specific values. > > > > > > Measurement Method role is not a defined term, but can be used to > > express the capability implemented within a MA (or MP) that allows it > > to participate in a Measurement Method. I see that various ippm RFCs > > use the word "role" in this way, including OWAMP and TWAMP. > > > > > > If there is a need to talk about an instance of executing a > > > Measurement > > Method, this could be called a Measurement Method instance. Again, > > without definition as a formal term. > > > > > > There exist several instances of "Measurement Method" that would > > > need > > to become "Measurement Method role". For example: > > > "A Measurement Task is a specific instantiation of a Measurement > > > Method role." > > > > > > Capabilities: Information about the performance measurement > > > capabilities of the MA, in particular the Measurement Method > roles that it > > > can perform, and the device hosting the MA, for example its > interface > > > type and speed, but not dynamic information. > > > > > > "the Measurement Method roles that the MA supports" > > > > > > But most discussion of Measurement Method in framework is of the > > Measurement Method and not the Measurement Method role. > > > > > > There is one instance where "Measurement Task capability" is used > in > > > the > > same sense as a Measurement Method role: "...Measurement Agents may > > come from > > > different vendors, be in wired and wireless networks, have > > > different Measurement Task capabilities and be on devices > with > > > IPv4 or IPv6 addresses." > > > > > > I found one instance where I question the use of "Measurement Task" > > > and > > wonder if it should be "Measurement Method": > > > "Some Measurement Tasks involve several MAs acting in a > coordinated > > > fashion." > > > > > > In my scan of framework, I couldn't find a place where I thought > > Measurement Task was used to mean a Measurement Method instance. > > > Barbara > > > > > > _______________________________________________ > > > 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 >=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 From nobody Mon Jun 9 09:56: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 6EAE81A01EF for ; Mon, 9 Jun 2014 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3qb1luSLDmZG for ; Mon, 9 Jun 2014 09:56:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B9B1A0274 for ; Mon, 9 Jun 2014 09:56:25 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 17:56:27 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 9 Jun 2014 17:56:23 +0100 From: To: , Date: Mon, 9 Jun 2014 17:56:22 +0100 Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7A= Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3321EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/PV4BkoS0497Z0vBaEnWUd_P6znw Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 16:56:29 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3321EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3321EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Over-ride migh= t make it a bit too easy to accidentally suppress a really crucial Task suc= h as reporting to the collector or communication with the controller (since= tasks are now general and not just measurement tasks).  Or deliberate= ly by an attacker.

&nbs= p;

If the controller wants to suppre= ss a task with the do-not-suppress flag set, then it would either re-does t= he task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com= ]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 = R; lmap@ietf.org
Subject: RE: Suppression in framework=

 

I would think that = information in the optional Suppress fields would override the default beha= vior flag. That is, if the do-not-suppress flag was set for a given task, y= et a Suppression message specifically listed that same task (or schedule co= ntaining the Task), the task would then be suppressed and no error would be= thrown.

 

 

From:<= /b> lmap [mailto:lmap-bounces= @ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PMTo: lmap@ietf.org
Subje= ct: [lmap] Suppression in framework

&nb= sp;

So we have agr= eed to modify suppression so the default behaviour is that tasks have a Boo= lean flag which indicates whether or not a Suppress message will suppress t= hem.

Question= : what do we want the impact of the flag to be when we have the more comple= x, optional Suppress message? (it lists specific Tasks or Schedules for sup= pression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 <= o:p>

 

Treating the Boolea= n flag as meaning “do-not-suppress this Measurement Task”, my p= roposal is to basically keep the current text unaltered:<= /p>

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    

<< Optionally the Suppression information may=

   include:

 <= /p>

&nb= sp;  o  a set of Measurement Tasks to suppress; the others are no= t

      suppressed.  For examp= le, this could be useful if a particular

   &= nbsp;  Measurement Task is overloading a Measurement Peer.<= /span>

 

   o  a set of Measurement Schedul= es to suppress; the others are not

    &= nbsp; suppressed.  For example, suppose the measurement system has

      defined two Schedules, one with = the most critical Measurement

     = Tasks and the other with less critical ones that create a lot of

      Active Measurement Traffic, then it ma= y only want to suppress the

      s= econd.

 

   o  a start ti= me, at which suppression begins

 

 = ;  o  an end time, at which suppression ends

=  

   o  a demand that the MA ends its on-goin= g Active Measurement Task(s)

      = (and deletes the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controlle= r says “Suppress Task #213” then the MA checks the do-not-suppr= ess flag for Task #213 and either throws an error or doesn’t start th= is Task. Similarly, if the Controller says “Suppress Schedule #49R= 21;, then the MA checks the do-not-suppress flag for Tasks in this schedule= and either throws an error or doesn’t start any new Tasks in this sc= hedule.

=  

I’ll = tweak the text to say this (as well as removing the refs to Active).

I’ll also mak= e clear that the Controller sets the do-not-suppress flag for a Task (it is= n’t something that the MA decides about).

 

Thanks

phil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3321EMV67UKRDdoma_-- From nobody Mon Jun 9 09:57: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 623041A0278 for ; Mon, 9 Jun 2014 09:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 4hjy2BWbMzBC for ; Mon, 9 Jun 2014 09:57:05 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381311A01EF for ; Mon, 9 Jun 2014 09:57:04 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o145.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 067e5935.2b92fe803940.14541.00-578.39248.p01c12o145.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 10:57:04 -0600 (MDT) X-MXL-Hash: 5395e7600553af0c-895e8774607744aff9b893a42f656c2fc3d55e8a Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o145.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 237e5935.0.14095.00-387.37976.p01c12o145.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 10:56:23 -0600 (MDT) X-MXL-Hash: 5395e737166b538c-8596c6d0aa858a1b7162ddc436613d4acc8198b4 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 11:56:18 -0500 From: KEN KO To: "philip.eardley@bt.com" , "acmorton@att.com" , "bs7652@att.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2A= Date: Mon, 9 Jun 2014 16:56:17 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=W7G2VHmk c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=O0zZt05sKgDmkvLVwk8A:9 a=CjuIK1q_8ugA:10 a=hnh-V3s2d3] X-AnalysisOut: [MA:10 a=FFJDkueNQTAA:10 a=_PH1qolPaM4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060920); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_dyKSrpjb44_xryXsBQZ_ztUYBw Subject: Re: [lmap] Measurement Methods and Tasks 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, 09 Jun 2014 16:57:06 -0000 > ... it's probably more consistent with ippm for it to be a registry of Me= thods. So then the ***Measurement Task Configuration*** needs an Input Para= meter (or some other kind of configuration option) to choose between differ= ent roles (client, server...) With that one (hopefully minor) tweak, +1 From nobody Mon Jun 9 10:05: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 A6F751A0281 for ; Mon, 9 Jun 2014 10:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 gXiJ_ngh-goI for ; Mon, 9 Jun 2014 10:05:38 -0700 (PDT) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347471A027B for ; Mon, 9 Jun 2014 10:05:38 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 269e5935.2ba7fa21c940.44344.00-532.124394.p02c11o148.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 11:05:38 -0600 (MDT) X-MXL-Hash: 5395e9620cafc827-444a36291af8f2ae2d7f904803442e94263a87ab Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id f49e5935.0.44091.00-278.123729.p02c11o148.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 11:05:25 -0600 (MDT) X-MXL-Hash: 5395e95517d36493-cfe8de0d00431927a91e0982957bc8fa626f3ac0 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 12:05:18 -0500 From: KEN KO To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwA== Date: Mon, 9 Jun 2014 17:05:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FDCCexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=C9hnyG/+ c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=qZHQZMT3apYA:10 a=eQt] X-AnalysisOut: [CghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=B6ve0Kc9lINE8ffzS18A:9 a=CjuIK1q_8ugA:10 a=W1qU_X6G3J8A] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a=yMhMjlubAAAA:8 a] X-AnalysisOut: [=SSmOFEACAAAA:8 a=d7ncxycqXtQjvNS92VUA:9 a=q0Fd8JL4U7Wv6rI] X-AnalysisOut: [f:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10] X-AnalysisOut: [ a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060920); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Pnz5y_37cgFUVN6n-kehBR9TF-E Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 17:05:41 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FDCCexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FDCCexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My interpretation of t= he existing text is that the option fields already override default behavio= r.

 

Given the more general= nature of Tasks as you point out, there may be specific tasks which should= simply never be suppressed, either by default configuration or optional fi= eld. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else= should be recoverable. And if that is true, I’m still in favor of th= e optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress= a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-supp= ress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.= KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would o= verride the default behavior flag. That is, if the do-not-suppress flag was= set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement Tasks to suppress; the oth= ers are not

      suppressed.  For example, this c= ould be useful if a particular

      Measurement Task is overloading a Mea= surement Peer.

 

   o  a set of Measurement Schedules to suppress; the= others are not

      suppressed.  For example, suppos= e the measurement system has

      defined two Schedules, one with the m= ost critical Measurement

      Tasks and the other with less critica= l ones that create a lot of

      Active Measurement Traffic, then it m= ay only want to suppress the

      second.

 

   o  a start time, at which suppression begins<= /o:p>

 

   o  an end time, at which suppression ends

 

   o  a demand that the MA ends its on-going Active M= easurement Task(s)

      (and deletes the associated partial M= easurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil

--_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FDCCexmb1corpadtran_-- From nobody Mon Jun 9 10:24: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 DB6401A02AD for ; Mon, 9 Jun 2014 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 ujOqnL_xBzIi for ; Mon, 9 Jun 2014 10:24:12 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EC51A02A7 for ; Mon, 9 Jun 2014 10:24:01 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 1bde5935.2ba84e843940.111616.00-2411.289519.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jun 2014 17:24:01 +0000 (UTC) X-MXL-Hash: 5395edb11fcf2a15-58e73ba16dd1c033534bb8ce244578489f1df86f Received: from unknown [144.160.229.23] by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with SMTP id 7ade5935.0.100487.00-2383.289266.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 09 Jun 2014 17:23:52 +0000 (UTC) X-MXL-Hash: 5395eda823b0bc37-31d38610239dc05fa50d8334f8754754ca76930a 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 s59Gorch021935; Mon, 9 Jun 2014 12:50:58 -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 s59Gok8f021142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 12:50:48 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 9 Jun 2014 16:50:37 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 12:50:37 -0400 From: "STARK, BARBARA H" To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAAvFaA= Date: Mon, 9 Jun 2014 16:50:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE794E@GAALPA1MSGUSRBF.ITServices.sbc.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.61.166.174] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE794EGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAA] X-AnalysisOut: [AA:8 a=Zzy5SpTdfIpvVvj-v3sA:9 a=CjuIK1q_8ugA:10 a=lZB815dz] X-AnalysisOut: [VvQA:10 a=W1qU_X6G3J8A:10 a=WHIDNrJZAwIn3Lvw:21 a=VF3AudZ-] X-AnalysisOut: [oZX564Jx:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=XIb417caq_] X-AnalysisOut: [oHI-yEcL4A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Y] X-AnalysisOut: [k6K0A:10 a=frz4AuCg-hUA:10 a=K2LbohMNYwtKnbbL:21 a=O00Qbvc] X-AnalysisOut: [g76zdW1bc:21 a=9YU4trGQpNleb_IK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-v6PZW5pSXM14VfCMj3uAezjfkY Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 17:24:20 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE794EGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Monday, June 09, 2014 12:49 PM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_2D09D61DDFA73D4C884805CC7865E61130DE794EGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

Barbara

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of KEN KO
Sent: Monday, June 09, 2014 12:49 PM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

I would think that inf= ormation in the optional Suppress fields would override the default behavio= r flag. That is, if the do-not-suppress flag was set for a given task, yet = a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be s= uppressed and no error would be thrown.

 

 

From: lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that t= asks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the mo= re complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measureme= nt Task”, my proposal is to basically keep the current text unaltered= :

            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;          

<<<=
/span> Optionally the Suppression information may<=
o:p>

=    include:

=  

=    o  a set of Measurement = Tasks to suppress; the others are not

=       suppressed.=   For example, this could be useful if a particular<= /p>

=       Measurement= Task is overloading a Measurement Peer.

=  

=    o  a set of Measurement = Schedules to suppress; the others are not

=       suppressed.=   For example, suppose the measurement system has

=       defined two= Schedules, one with the most critical Measurement

=       Tasks and t= he other with less critical ones that create a lot of

=       Active Meas= urement Traffic, then it may only want to suppress the

=       second.

=  

=    o  a start time, at whic= h suppression begins

=  

=    o  an end time, at which= suppression ends

=  

=    o  a demand that the MA = ends its on-going Active Measurement Task(s)

=       (and delete= s the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” th= en the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Act= ive).

I’ll also make clear that the Controller sets the do-not-suppress fl= ag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil

--_000_2D09D61DDFA73D4C884805CC7865E61130DE794EGAALPA1MSGUSRBF_-- From nobody Mon Jun 9 10:50: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 C18481A0294 for ; Mon, 9 Jun 2014 10:50:18 -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 F0OX71ACAsUt for ; Mon, 9 Jun 2014 10:50:17 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A161A0293 for ; Mon, 9 Jun 2014 10:50:17 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s59Ho5wS022078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 12:50:06 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id ADA9C1E0065; Mon, 9 Jun 2014 11:50:00 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 8BEF71E0055; Mon, 9 Jun 2014 11:50:00 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59Ho0Ve004446; Mon, 9 Jun 2014 11:50:00 -0600 (MDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59HnxDw004438; Mon, 9 Jun 2014 11:49:59 -0600 (MDT) Message-ID: <5395F3C7.6090005@centurylink.com> Date: Mon, 09 Jun 2014 11:49:59 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "philip.eardley@bt.com" , "acmorton@att.com" , "bs7652@att.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> In-Reply-To: X-Enigmail-Version: 1.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/925JeO4AWwD1sW1nSlHUo5VtPXI Subject: Re: [lmap] Measurement Methods and Tasks 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: Mon, 09 Jun 2014 17:50:18 -0000 If I understand correctly, the Measurement Method defines all the possible roles. The Measurement Task generated by the Control sets an Input parameter that selects the role the MA is to perform. Charles On 6/9/2014 10:56 AM, KEN KO wrote: >> ... it's probably more consistent with ippm for it to be a registry of Methods. So then the ***Measurement Task Configuration*** needs an Input Parameter (or some other kind of configuration option) to choose between different roles (client, server...) > With that one (hopefully minor) tweak, +1 > -- 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 Mon Jun 9 10:59: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 D42C71A028D for ; Mon, 9 Jun 2014 10:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 T8thI5yhcuey for ; Mon, 9 Jun 2014 10:59:53 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6A01A0280 for ; Mon, 9 Jun 2014 10:59:53 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s59HxjV2000914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 12:59:45 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id EC42D1E006D; Mon, 9 Jun 2014 11:59:39 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 448E41E005E; Mon, 9 Jun 2014 11:59:39 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59Hxcp1011299; Mon, 9 Jun 2014 11:59:38 -0600 (MDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59HxbFS011283; Mon, 9 Jun 2014 11:59:37 -0600 (MDT) Message-ID: <5395F609.8020003@centurylink.com> Date: Mon, 09 Jun 2014 11:59:37 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080803010509040203050203" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/cfR_WV5Mg69qr7RtNISvrbYC2sE Subject: Re: [lmap] Suppression in framework 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: Mon, 09 Jun 2014 17:59:56 -0000 This is a multi-part message in MIME format. --------------080803010509040203050203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Measurement Method. If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method. If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller. Charles On 6/9/2014 11:05 AM, KEN KO wrote: > > My interpretation of the existing text is that the option fields > already override default behavior. > > > > Given the more general nature of Tasks as you point out, there may be > specific tasks which should simply never be suppressed, either by > default configuration or optional field. I'm thinking primarily about > communication with the Controller. If we protect that, then > suppression of anything else should be recoverable. And if that is > true, I'm still in favor of the optional fields overriding the default. > > > > Your thoughts? > > > > *From:*philip.eardley@bt.com [mailto:philip.eardley@bt.com] > *Sent:* Monday, June 09, 2014 12:56 PM > *To:* KEN KO; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > Over-ride might make it a bit too easy to accidentally suppress a > really crucial Task such as reporting to the collector or > communication with the controller (since tasks are now general and not > just measurement tasks). Or deliberately by an attacker. > > > > If the controller wants to suppress a task with the do-not-suppress > flag set, then it would either re-does the task configuration or it > updates the schedule > > > > *From:*KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* 09 June 2014 17:49 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > I would think that information in the optional Suppress fields would > override the default behavior flag. That is, if the do-not-suppress > flag was set for a given task, yet a Suppression message specifically > listed that same task (or schedule containing the Task), the task > would then be suppressed and no error would be thrown. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* Monday, June 09, 2014 12:43 PM > *To:* lmap@ietf.org > *Subject:* [lmap] Suppression in framework > > > > So we have agreed to modify suppression so the default behaviour is > that tasks have a Boolean flag which indicates whether or not a > Suppress message will suppress them. > > Question: what do we want the impact of the flag to be when we have > the more complex, optional Suppress message? (it lists specific Tasks > or Schedules for suppression.) > > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 > > > > Treating the Boolean flag as meaning "do-not-suppress this Measurement > Task", my proposal is to basically keep the current text unaltered: > > > > > << Optionally the Suppression information may > > include: > > > > o a set of Measurement Tasks to suppress; the others are not > > suppressed. For example, this could be useful if a particular > > Measurement Task is overloading a Measurement Peer. > > > > o a set of Measurement Schedules to suppress; the others are not > > suppressed. For example, suppose the measurement system has > > defined two Schedules, one with the most critical Measurement > > Tasks and the other with less critical ones that create a lot of > > Active Measurement Traffic, then it may only want to suppress the > > second. > > > > o a start time, at which suppression begins > > > > o an end time, at which suppression ends > > > > o a demand that the MA ends its on-going Active Measurement Task(s) > > (and deletes the associated partial Measurement Result(s)). > > >> > > > > In other words, if the Controller says "Suppress Task #213" then the > MA checks the do-not-suppress flag for Task #213 and either throws an > error or doesn't start this Task. Similarly, if the Controller says > "Suppress Schedule #49", then the MA checks the do-not-suppress flag > for Tasks in this schedule and either throws an error or doesn't start > any new Tasks in this schedule. > > > > I'll tweak the text to say this (as well as removing the refs to Active). > > I'll also make clear that the Controller sets the do-not-suppress flag > for a Task (it isn't something that the MA decides about). > > > > Thanks > > phil > > > > _______________________________________________ > 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 --------------080803010509040203050203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Measurement Method.  If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method.  If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task.

I have not formed an opinion regarding MA communication with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the option fields already override default behavior.

 

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-suppress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would override the default behavior flag. That is, if the do-not-suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the more complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurement Task”, my proposal is to basically keep the current text unaltered:

                                                                                     

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to suppress; the others are not

      suppressed.  For example, this could be useful if a particular

      Measurement Task is overloading a Measurement Peer.

 

   o  a set of Measurement Schedules to suppress; the others are not

      suppressed.  For example, suppose the measurement system has

      defined two Schedules, one with the most critical Measurement

      Tasks and the other with less critical ones that create a lot of

      Active Measurement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at which suppression begins

 

   o  an end time, at which suppression ends

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)

      (and deletes the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller says “Suppress Schedule #49”, then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn’t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Active).

I’ll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil



_______________________________________________
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
--------------080803010509040203050203-- From nobody Mon Jun 9 11:13:14 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 C4B131A029A for ; Mon, 9 Jun 2014 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 rGezJ8aCJExy for ; Mon, 9 Jun 2014 11:13:08 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3371A0294 for ; Mon, 9 Jun 2014 11:13:08 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 439f5935.2b42d9c9d940.16719.00-517.44971.p01c12o141.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 12:13:08 -0600 (MDT) X-MXL-Hash: 5395f9342a571acd-60d12a97999b9574e654350ee88d0900d1f188ed Received: from unknown [76.164.174.82] by p01c12o141.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id e09f5935.0.16271.00-263.43631.p01c12o141.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 12:12:34 -0600 (MDT) X-MXL-Hash: 5395f9120ecc87e2-12e6fd375c2b7ed8ca214afa0d4573adfe26dfc8 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 13:12:29 -0500 From: KEN KO To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "acmorton@att.com" , "bs7652@att.com" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/w Date: Mon, 9 Jun 2014 18:12:28 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> In-Reply-To: <5395F3C7.6090005@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=SKDMVYfH c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=J_N6KFswAAAA:8 a=e9qsufxtAAAA:8 a=zQP7CpKOAAAA:8 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=cqf2HY-BleLwsuWt_DEA:9 a=CjuIK1q_8ugA:10 a=] X-AnalysisOut: [fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a=Pwbduc0PQ3sA:10 a=W1qU] X-AnalysisOut: [_X6G3J8A:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060922); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jcN-7OM-691g4RnrfAP2ZYS3Eac Subject: Re: [lmap] Measurement Methods and Tasks 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, 09 Jun 2014 18:13:10 -0000 Yes, that is how I interpret it. -----Original Message----- From: Charles Cook [mailto:charles.cook2@centurylink.com]=20 Sent: Monday, June 09, 2014 1:50 PM To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com; lmap@i= etf.org Subject: Re: [lmap] Measurement Methods and Tasks If I understand correctly, the Measurement Method defines all the possible = roles. The Measurement Task generated by the Control sets an Input paramet= er that selects the role the MA is to perform. Charles On 6/9/2014 10:56 AM, KEN KO wrote: >> ... it's probably more consistent with ippm for it to be a registry=20 >> of Methods. So then the ***Measurement Task Configuration*** needs an=20 >> Input Parameter (or some other kind of configuration option) to=20 >> choose between different roles (client, server...) > With that one (hopefully minor) tweak, +1 > --=20 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 Mon Jun 9 11:20: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 C0D6E1A02A0 for ; Mon, 9 Jun 2014 11:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 B_ZTl3JqMph7 for ; Mon, 9 Jun 2014 11:20:02 -0700 (PDT) Received: from p02c11o142.mxlogic.net (p02c11o142.mxlogic.net [208.65.144.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9911A0294 for ; Mon, 9 Jun 2014 11:20:01 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o142.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 1daf5935.2b8e0e873940.22531.00-495.62341.p02c11o142.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 12:20:01 -0600 (MDT) X-MXL-Hash: 5395fad167f55dd1-db580f8c61bb2c052de157a3db52a25749b4e170 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o142.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id b9af5935.0.21931.00-316.60735.p02c11o142.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 12:19:09 -0600 (MDT) X-MXL-Hash: 5395fa9d5963b0ff-711e25ddaa2071ea9b68837176f428a93b11adb5 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 13:19:07 -0500 From: KEN KO To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYA= Date: Mon, 9 Jun 2014 18:19:06 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> In-Reply-To: <5395F609.8020003@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FEDCexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=CIOkXHbD c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=J_N6KFswAAAA:] X-AnalysisOut: [8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=vrudC_vgUdM9LsO-xAUA] X-AnalysisOut: [:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a] X-AnalysisOut: [=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA:10 a=Dvn] X-AnalysisOut: [SUQUdWHYA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=IJbND13m3] X-AnalysisOut: [6DAPzSqlCgA:9 a=_0fPIgn9uPGupyME:21 a=gKO2Hq4RSVkA:10 a=Ui] X-AnalysisOut: [CQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060923); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Purapg4Vuzm1G9BJVxtdVlxB3j0 Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 18:20:06 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FEDCexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FEDCexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charles,

 

Is there a reason to p= revent the do-not-suppress flag from redefining the default suppression beh= avior suggested for a particular Measurement Method in a Registry, yet stil= l allow it to be overridden by the optional suppression fields? Seems like that would be a needless limitation on the = information model.

 

Ken<= /p>

 

From: Charles Cook [mailto:c= harles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On 6/9/2014 11:05 AM, KEN= KO wrote:

My interpretation of the existing text is that the option fields alrea= dy override default behavior.

 

Given the more general nature of Tasks as you point out, there may be = specific tasks which should simply never be suppressed, either by default c= onfiguration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, the= n suppression of anything else should be recoverable. And if that is true, = I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN= .KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppress fields would = override the default behavior flag. That is, if the do-not-suppress flag wa= s set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement Tasks to= suppress; the others are not

      suppressed.  F= or example, this could be useful if a particular

      Measurement Task is= overloading a Measurement Peer.

 

   o  a set of Measurement Schedule= s to suppress; the others are not

      suppressed.  F= or example, suppose the measurement system has

      defined two Schedul= es, one with the most critical Measurement

      Tasks and the other= with less critical ones that create a lot of

      Active Measurement = Traffic, then it may only want to suppress the

      second.=

 

   o  a start time, at which suppre= ssion begins

 

   o  an end time, at which suppres= sion ends

 

   o  a demand that the MA ends its= on-going Active Measurement Task(s)

      (and deletes the as= sociated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil




___________________________________________=
____
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:  92=
5.281.0662


charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FEDCexmb1corpadtran_-- From nobody Mon Jun 9 11:24: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 C77A41A029B for ; Mon, 9 Jun 2014 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 U14vJiExBtpb for ; Mon, 9 Jun 2014 11:24:29 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C490B1A029A for ; Mon, 9 Jun 2014 11:24:28 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id cdbf5935.2ad1186ad940.2385930.00-2454.6651546.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jun 2014 18:24:28 +0000 (UTC) X-MXL-Hash: 5395fbdc12ed5040-a003ef553f638c1ea6531dca41000c65160126be Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 6cbf5935.0.2385682.00-2354.6650797.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 09 Jun 2014 18:24:07 +0000 (UTC) X-MXL-Hash: 5395fbc71826574f-526baa852aaedae11cdb2e927a342cf9e47ab8b6 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 s59IO6DX021301; Mon, 9 Jun 2014 14:24:06 -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 s59INu1Z021229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 14:24:02 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 9 Jun 2014 18:23:46 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 14:23:46 -0400 From: "STARK, BARBARA H" To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAABGRJw Date: Mon, 9 Jun 2014 18:23:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE7A54@GAALPA1MSGUSRBF.ITServices.sbc.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.61.166.174] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE7A54GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BqQqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAA] X-AnalysisOut: [AA:8 a=eJNrpioGAAAA:8 a=Q4gNHlGBUHI_1c6VFi4A:9 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=DvnSUQUdWHYA:] X-AnalysisOut: [10 a=IAFEQK_P1BQW5C7Y:21 a=LR262mRG4xJN6UI1:21 a=yMhMjlubA] X-AnalysisOut: [AAA:8 a=SSmOFEACAAAA:8 a=2YbZ59l-CV8lYw5wrzoA:9 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10 a=Z1RYxE2lWKgYBWgK:21 a=x9ndJ4rt9wQte4-z:21 a=LOYfu8A3] X-AnalysisOut: [P9fJMQJ3:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/RxWUJZddJ7W2aU2fFXIzloSbYok Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 18:24:32 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE7A54GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Monday, June 09, 2014 1:05 PM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil --_000_2D09D61DDFA73D4C884805CC7865E61130DE7A54GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

Barbara

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of KEN KO
Sent: Monday, June 09, 2014 1:05 PM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My interpretation of t= he existing text is that the option fields already override default behavio= r.

 

Given the more general= nature of Tasks as you point out, there may be specific tasks which should= simply never be suppressed, either by default configuration or optional fi= eld. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else= should be recoverable. And if that is true, I’m still in favor of th= e optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress= a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-supp= ress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.= KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would o= verride the default behavior flag. That is, if the do-not-suppress flag was= set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement Tasks to= suppress; the others are not

      suppressed.  F= or example, this could be useful if a particular

      Measurement Task is= overloading a Measurement Peer.

 

   o  a set of Measurement Schedule= s to suppress; the others are not

      suppressed.  F= or example, suppose the measurement system has

      defined two Schedul= es, one with the most critical Measurement

      Tasks and the other= with less critical ones that create a lot of

      Active Measurement = Traffic, then it may only want to suppress the

      second.<= /span>

 

   o  a start time, at which suppre= ssion begins

 

   o  an end time, at which suppres= sion ends

 

   o  a demand that the MA ends its= on-going Active Measurement Task(s)

      (and deletes the as= sociated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil

--_000_2D09D61DDFA73D4C884805CC7865E61130DE7A54GAALPA1MSGUSRBF_-- From nobody Mon Jun 9 12:14: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 812C01A02D5 for ; Mon, 9 Jun 2014 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 7mvjZpQ6YZOp for ; Mon, 9 Jun 2014 12:14:55 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0381A029F for ; Mon, 9 Jun 2014 12:14:54 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s59JEk3F004914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 14:14:47 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 907421E0079; Mon, 9 Jun 2014 14:14:41 -0500 (CDT) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5A9601E005B; Mon, 9 Jun 2014 14:14:41 -0500 (CDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59JEeuv010674; Mon, 9 Jun 2014 13:14:40 -0600 (MDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59JEd16010638; Mon, 9 Jun 2014 13:14:39 -0600 (MDT) Message-ID: <5396079F.9070106@centurylink.com> Date: Mon, 09 Jun 2014 13:14:39 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" References: <5395F609.8020003@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070002080404050507080005" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Lfj_cXlMSdS7Ra6sk-KshaAgGos Subject: Re: [lmap] Suppression in framework 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: Mon, 09 Jun 2014 19:14:57 -0000 This is a multi-part message in MIME format. --------------070002080404050507080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ken, I'm not sure I follow your question. If there is a Measurement Method that has been defined a priori such that the Suppression behavior defined in the Measurement Method is not to be over-written, there should be a flag set to indicate that the Suppression behavior cannot be modified. In other words, if the defined suppression behavior is permitted to be changed, a flag in the Measurement Method would be set to Suppression_Behavior_Modifiable : True. A possible use case is one where a Network owner wants to maintain control of what third-parties do relative to Suppression behavior on the owner's Network. It is possible that the owner of a Network could create a registry of Measurement Methods that are allowable on their Network by third parties that are using a third-party Controller to measure portions of the owner's Network. The owner of the Network may determine that within the set of Measurement Methods, there may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is sent, and does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: > > Charles, > > > > Is there a reason to prevent the do-not-suppress flag from redefining > the default suppression behavior suggested for a particular > Measurement Method in a Registry, yet still allow it to be overridden > by the optional suppression fields? Seems like that would be a > needless limitation on the information model. > > > > Ken > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 2:00 PM > *To:* KEN KO; philip.eardley@bt.com; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Regarding suppression (not communication with the Controller): > My take is that the default suppression behavior can be coded into the > Measurement Method. If there is a possibility that the default can be > overwritten, then an optional field is added to the Measurement > Method. If the Controller wants to override the default, it must > assert the optional override field when generating the Measurement Task. > > I have not formed an opinion regarding MA communication with the > Controller. > > Charles > > On 6/9/2014 11:05 AM, KEN KO wrote: > > My interpretation of the existing text is that the option fields > already override default behavior. > > > > Given the more general nature of Tasks as you point out, there may > be specific tasks which should simply never be suppressed, either > by default configuration or optional field. I'm thinking primarily > about communication with the Controller. If we protect that, then > suppression of anything else should be recoverable. And if that is > true, I'm still in favor of the optional fields overriding the > default. > > > > Your thoughts? > > > > *From:*philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > *Sent:* Monday, June 09, 2014 12:56 PM > *To:* KEN KO; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > Over-ride might make it a bit too easy to accidentally suppress a > really crucial Task such as reporting to the collector or > communication with the controller (since tasks are now general and > not just measurement tasks). Or deliberately by an attacker. > > > > If the controller wants to suppress a task with the > do-not-suppress flag set, then it would either re-does the task > configuration or it updates the schedule > > > > *From:*KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* 09 June 2014 17:49 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > I would think that information in the optional Suppress fields > would override the default behavior flag. That is, if the > do-not-suppress flag was set for a given task, yet a Suppression > message specifically listed that same task (or schedule containing > the Task), the task would then be suppressed and no error would be > thrown. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* Monday, June 09, 2014 12:43 PM > *To:* lmap@ietf.org > *Subject:* [lmap] Suppression in framework > > > > So we have agreed to modify suppression so the default behaviour > is that tasks have a Boolean flag which indicates whether or not a > Suppress message will suppress them. > > Question: what do we want the impact of the flag to be when we > have the more complex, optional Suppress message? (it lists > specific Tasks or Schedules for suppression.) > > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 > > > > Treating the Boolean flag as meaning "do-not-suppress this > Measurement Task", my proposal is to basically keep the current > text unaltered: > > > > > << Optionally the Suppression information may > > include: > > > > o a set of Measurement Tasks to suppress; the others are not > > suppressed. For example, this could be useful if a particular > > Measurement Task is overloading a Measurement Peer. > > > > o a set of Measurement Schedules to suppress; the others are not > > suppressed. For example, suppose the measurement system has > > defined two Schedules, one with the most critical Measurement > > Tasks and the other with less critical ones that create a lot of > > Active Measurement Traffic, then it may only want to > suppress the > > second. > > > > o a start time, at which suppression begins > > > > o an end time, at which suppression ends > > > > o a demand that the MA ends its on-going Active Measurement > Task(s) > > (and deletes the associated partial Measurement Result(s)). > > >> > > > > In other words, if the Controller says "Suppress Task #213" then > the MA checks the do-not-suppress flag for Task #213 and either > throws an error or doesn't start this Task. Similarly, if the > Controller says "Suppress Schedule #49", then the MA checks the > do-not-suppress flag for Tasks in this schedule and either throws > an error or doesn't start any new Tasks in this schedule. > > > > I'll tweak the text to say this (as well as removing the refs to > Active). > > I'll also make clear that the Controller sets the do-not-suppress > flag for a Task (it isn't something that the MA decides about). > > > > Thanks > > phil > > > > > _______________________________________________ > > 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 -- 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 --------------070002080404050507080005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ken,

I'm not sure I follow your question.  If there is a Measurement Method that has been defined a priori such that the Suppression behavior defined in the Measurement Method is not to be over-written, there should be a flag set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppression behavior is permitted to be changed, a flag in the Measurement Method would be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control of what third-parties do relative to Suppression behavior on the owner's Network.  It is possible that the owner of a Network could create a registry of Measurement Methods that are allowable on their Network by third parties that are using  a third-party Controller to measure portions of the owner's Network.  The owner of the Network may determine that within the set of Measurement Methods, there may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is sent, and does not want the third-party Controller to ever override that behavior.

If the Network owner also owns the Controller, then I can't think of a good reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag from redefining the default suppression behavior suggested for a particular Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Measurement Method.  If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method.  If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task.

I have not formed an opinion regarding MA communication with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the option fields already override default behavior.

 

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-suppress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would override the default behavior flag. That is, if the do-not-suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the more complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurement Task”, my proposal is to basically keep the current text unaltered:

                                                                                     

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to suppress; the others are not

      suppressed.  For example, this could be useful if a particular

      Measurement Task is overloading a Measurement Peer.

 

   o  a set of Measurement Schedules to suppress; the others are not

      suppressed.  For example, suppose the measurement system has

      defined two Schedules, one with the most critical Measurement

      Tasks and the other with less critical ones that create a lot of

      Active Measurement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at which suppression begins

 

   o  an end time, at which suppression ends

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)

      (and deletes the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller says “Suppress Schedule #49”, then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn’t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Active).

I’ll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil




_______________________________________________
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

-- 

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
--------------070002080404050507080005-- From nobody Mon Jun 9 12:36:28 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 B4D4A1A0313 for ; Mon, 9 Jun 2014 12:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 mwbzrrJoz-bo for ; Mon, 9 Jun 2014 12:36:21 -0700 (PDT) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A7B1A02F4 for ; Mon, 9 Jun 2014 12:36:21 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 5bc06935.2b281fe33940.8276.00-508.22587.p02c11o148.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 13:36:21 -0600 (MDT) X-MXL-Hash: 53960cb53fc625e1-bfd10a4ca2425500b21d6aa48b341b616529420f Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o148.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id c8c06935.0.7781.00-340.21249.p02c11o148.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 13:35:50 -0600 (MDT) X-MXL-Hash: 53960c9668e1b447-ca3287c34f4321376a2ce9542a156cf70679d574 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 14:35:39 -0500 From: KEN KO To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw Date: Mon, 9 Jun 2014 19:35:38 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> In-Reply-To: <5396079F.9070106@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FFB9exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=bqrCBSqi c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=J_N6KFswAAAA:] X-AnalysisOut: [8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=jCScaEdgAI_3U5l4InQA] X-AnalysisOut: [:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a] X-AnalysisOut: [=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA:10 a=Dvn] X-AnalysisOut: [SUQUdWHYA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=kF5tFUr_H] X-AnalysisOut: [_F5kEw0:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6] X-AnalysisOut: [K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060928); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/WoBYqW2cUhT3M1IuvI85-M7mjas Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 19:36:26 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FFB9exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FFB9exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, thanks. I read it = wrong the first time. I can see some utility in that, but it does complicat= e the MA which would have to test suppression configuration in the Task aga= inst what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:c= harles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN= KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag from redefining = the default suppression behavior suggested for a particular Measurement Met= hod in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would= be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On 6/9/2014 11:05 AM, KE= N KO wrote:

My interpretation of the existing text is that the option fields alre= ady override default behavior.

 

Given the more general nature of Tasks as you point out, there may be= specific tasks which should simply never be suppressed, either by default = configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, the= n suppression of anything else should be recoverable. And if that is true, = I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN= .KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppress fields would = override the default behavior flag. That is, if the do-not-suppress flag wa= s set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement = Tasks to suppress; the others are not

      suppressed.=   For example, this could be useful if a particular<= /p>

      Measurement= Task is overloading a Measurement Peer.

 

   o  a set of Measurement = Schedules to suppress; the others are not

      suppressed.=   For example, suppose the measurement system has

      defined two= Schedules, one with the most critical Measurement

      Tasks and t= he other with less critical ones that create a lot of

      Active Meas= urement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at whic= h suppression begins

 

   o  an end time, at which= suppression ends

 

   o  a demand that the MA = ends its on-going Active Measurement Task(s)

      (and delete= s the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil

= 



__________________________________________=
_____
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:  9=
25.281.0662


charles.cook2@centurylink.com





-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224

Denver, CO  80221


Tel:  303.992.8952  Fax:  92=
5.281.0662


charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB77756FFB9exmb1corpadtran_-- From nobody Mon Jun 9 13:16: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 BA9CA1A02E2 for ; Mon, 9 Jun 2014 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 qKVMjguB1ZHw for ; Mon, 9 Jun 2014 13:16:44 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70D71A01B9 for ; Mon, 9 Jun 2014 13:16:44 -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 s59KGYs6009738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 14:16:35 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9C7A71E00CA; Mon, 9 Jun 2014 15:16:29 -0500 (CDT) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5FB061E00C6; Mon, 9 Jun 2014 15:16:29 -0500 (CDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59KGSnP012616; Mon, 9 Jun 2014 14:16:28 -0600 (MDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s59KGRGM012573; Mon, 9 Jun 2014 14:16:27 -0600 (MDT) Message-ID: <5396161B.3050509@centurylink.com> Date: Mon, 09 Jun 2014 14:16:27 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------050909070007060009060007" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9hFqmJ87uSxw8ZS7O8WsyoI0TIo Subject: Re: [lmap] Suppression in framework 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: Mon, 09 Jun 2014 20:16:47 -0000 This is a multi-part message in MIME format. --------------050909070007060009060007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Good point. Or the Controller can do the configuration manipulation in the creation of the Measurement Task (my preference) so the MA does not have to. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: > > OK, thanks. I read it wrong the first time. I can see some utility in > that, but it does complicate the MA which would have to test > suppression configuration in the Task against what is allowed by the > Measurement Method. > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 3:15 PM > *To:* KEN KO; philip.eardley@bt.com; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Ken, > > I'm not sure I follow your question. If there is a Measurement Method > that has been defined a priori such that the Suppression behavior > defined in the Measurement Method is not to be over-written, there > should be a flag set to indicate that the Suppression behavior cannot > be modified. In other words, if the defined suppression behavior is > permitted to be changed, a flag in the Measurement Method would be set > to Suppression_Behavior_Modifiable : True. > > A possible use case is one where a Network owner wants to maintain > control of what third-parties do relative to Suppression behavior on > the owner's Network. It is possible that the owner of a Network could > create a registry of Measurement Methods that are allowable on their > Network by third parties that are using a third-party Controller to > measure portions of the owner's Network. The owner of the Network may > determine that within the set of Measurement Methods, there may be a > subset of Measurement Methods that the Network Owner always wants to > be suppressed when a suppression is sent, and does not want the > third-party Controller to ever override that behavior. > > If the Network owner also owns the Controller, then I can't think of a > good reason to consider this method of dealing with Suppression. > > Charles > > On 6/9/2014 12:19 PM, KEN KO wrote: > > Charles, > > > > Is there a reason to prevent the do-not-suppress flag from > redefining the default suppression behavior suggested for a > particular Measurement Method in a Registry, yet still allow it to > be overridden by the optional suppression fields? Seems like that > would be a needless limitation on the information model. > > > > Ken > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 2:00 PM > *To:* KEN KO; philip.eardley@bt.com > ; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Regarding suppression (not communication with the Controller): > My take is that the default suppression behavior can be coded into > the Measurement Method. If there is a possibility that the > default can be overwritten, then an optional field is added to the > Measurement Method. If the Controller wants to override the > default, it must assert the optional override field when > generating the Measurement Task. > > I have not formed an opinion regarding MA communication with the > Controller. > > Charles > > On 6/9/2014 11:05 AM, KEN KO wrote: > > My interpretation of the existing text is that the option > fields already override default behavior. > > > > Given the more general nature of Tasks as you point out, there > may be specific tasks which should simply never be suppressed, > either by default configuration or optional field. I'm > thinking primarily about communication with the Controller. If > we protect that, then suppression of anything else should be > recoverable. And if that is true, I'm still in favor of the > optional fields overriding the default. > > > > Your thoughts? > > > > *From:*philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > *Sent:* Monday, June 09, 2014 12:56 PM > *To:* KEN KO; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > Over-ride might make it a bit too easy to accidentally > suppress a really crucial Task such as reporting to the > collector or communication with the controller (since tasks > are now general and not just measurement tasks). Or > deliberately by an attacker. > > > > If the controller wants to suppress a task with the > do-not-suppress flag set, then it would either re-does the > task configuration or it updates the schedule > > > > *From:*KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* 09 June 2014 17:49 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > *Subject:* RE: Suppression in framework > > > > I would think that information in the optional Suppress fields > would override the default behavior flag. That is, if the > do-not-suppress flag was set for a given task, yet a > Suppression message specifically listed that same task (or > schedule containing the Task), the task would then be > suppressed and no error would be thrown. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* Monday, June 09, 2014 12:43 PM > *To:* lmap@ietf.org > *Subject:* [lmap] Suppression in framework > > > > So we have agreed to modify suppression so the default > behaviour is that tasks have a Boolean flag which indicates > whether or not a Suppress message will suppress them. > > Question: what do we want the impact of the flag to be when we > have the more complex, optional Suppress message? (it lists > specific Tasks or Schedules for suppression.) > > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 > > > > Treating the Boolean flag as meaning "do-not-suppress this > Measurement Task", my proposal is to basically keep the > current text unaltered: > > > > > << Optionally the Suppression information may > > include: > > > > o a set of Measurement Tasks to suppress; the others are not > > suppressed. For example, this could be useful if a > particular > > Measurement Task is overloading a Measurement Peer. > > > > o a set of Measurement Schedules to suppress; the others > are not > > suppressed. For example, suppose the measurement system has > > defined two Schedules, one with the most critical > Measurement > > Tasks and the other with less critical ones that create > a lot of > > Active Measurement Traffic, then it may only want to > suppress the > > second. > > > > o a start time, at which suppression begins > > > > o an end time, at which suppression ends > > > > o a demand that the MA ends its on-going Active > Measurement Task(s) > > (and deletes the associated partial Measurement Result(s)). > > >> > > > > In other words, if the Controller says "Suppress Task #213" > then the MA checks the do-not-suppress flag for Task #213 and > either throws an error or doesn't start this Task. Similarly, > if the Controller says "Suppress Schedule #49", then the MA > checks the do-not-suppress flag for Tasks in this schedule and > either throws an error or doesn't start any new Tasks in this > schedule. > > > > I'll tweak the text to say this (as well as removing the refs > to Active). > > I'll also make clear that the Controller sets the > do-not-suppress flag for a Task (it isn't something that the > MA decides about). > > > > Thanks > > phil > > > > > > _______________________________________________ > > 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 > > > > -- > > 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 -- 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 --------------050909070007060009060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Good point.  Or the Controller can do the configuration manipulation in the creation of the Measurement Task (my preference) so the MA does not have to.  - keep the MA as simple as possible at the expense of the Controller.

Charles

On 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see some utility in that, but it does complicate the MA which would have to test suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method that has been defined a priori such that the Suppression behavior defined in the Measurement Method is not to be over-written, there should be a flag set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppression behavior is permitted to be changed, a flag in the Measurement Method would be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control of what third-parties do relative to Suppression behavior on the owner's Network.  It is possible that the owner of a Network could create a registry of Measurement Methods that are allowable on their Network by third parties that are using  a third-party Controller to measure portions of the owner's Network.  The owner of the Network may determine that within the set of Measurement Methods, there may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is sent, and does not want the third-party Controller to ever override that behavior.

If the Network owner also owns the Controller, then I can't think of a good reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag from redefining the default suppression behavior suggested for a particular Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Measurement Method.  If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method.  If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task.

I have not formed an opinion regarding MA communication with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the option fields already override default behavior.

 

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-suppress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would override the default behavior flag. That is, if the do-not-suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the more complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurement Task”, my proposal is to basically keep the current text unaltered:

                                                                                     

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to suppress; the others are not

      suppressed.  For example, this could be useful if a particular

      Measurement Task is overloading a Measurement Peer.

 

   o  a set of Measurement Schedules to suppress; the others are not

      suppressed.  For example, suppose the measurement system has

      defined two Schedules, one with the most critical Measurement

      Tasks and the other with less critical ones that create a lot of

      Active Measurement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at which suppression begins

 

   o  an end time, at which suppression ends

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)

      (and deletes the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller says “Suppress Schedule #49”, then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn’t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Active).

I’ll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil





_______________________________________________
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



-- 
 
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

-- 

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
--------------050909070007060009060007-- From nobody Mon Jun 9 13:43: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 99ED11A0322 for ; Mon, 9 Jun 2014 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 5Snu8rkSh4JG for ; Mon, 9 Jun 2014 13:43:10 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F041A0329 for ; Mon, 9 Jun 2014 13:43:10 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s59Kgs07014553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 15:42:54 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5A4041E0053; Mon, 9 Jun 2014 14:42:49 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2B1181E004D; Mon, 9 Jun 2014 14:42:49 -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 s59Kgmir002601; Mon, 9 Jun 2014 15:42:48 -0500 (CDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id s59KgkdU002595; Mon, 9 Jun 2014 15:42:46 -0500 (CDT) Message-ID: <53961C47.7040708@centurylink.com> Date: Mon, 09 Jun 2014 14:42:47 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "philip.eardley@bt.com" , "lmap@ietf.org" References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------010406080700070803020803" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eJIHiGSYDUk7IYpmXaa2FIgx9mQ Subject: Re: [lmap] Suppression in framework 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: Mon, 09 Jun 2014 20:43:13 -0000 This is a multi-part message in MIME format. --------------010406080700070803020803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As soon as I hit send, that thought occurred to me as well, and whether it would be out of scope. Your comment on the MA having to test the configuration against what is allowed by the Measurement Method may be more trust worthy from the perspective of the Network owner than the third-party Controller. The Network owner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement between parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: > > But if a third party Controller can be trusted to do the right thing, > then there seems to be little value in a flag in the Measurement > Method that prohibits doing the wrong thing. > > > > Perhaps if that is the case, this is better handled by an agreement > between parties that would be out of scope for lmap? > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 4:16 PM > *To:* KEN KO; philip.eardley@bt.com; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Good point. Or the Controller can do the configuration manipulation > in the creation of the Measurement Task (my preference) so the MA does > not have to. - keep the MA as simple as possible at the expense of > the Controller. > > Charles > > On 6/9/2014 1:35 PM, KEN KO wrote: > > OK, thanks. I read it wrong the first time. I can see some utility > in that, but it does complicate the MA which would have to test > suppression configuration in the Task against what is allowed by > the Measurement Method. > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 3:15 PM > *To:* KEN KO; philip.eardley@bt.com > ; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Ken, > > I'm not sure I follow your question. If there is a Measurement > Method that has been defined a priori such that the Suppression > behavior defined in the Measurement Method is not to be > over-written, there should be a flag set to indicate that the > Suppression behavior cannot be modified. In other words, if the > defined suppression behavior is permitted to be changed, a flag in > the Measurement Method would be set to > Suppression_Behavior_Modifiable : True. > > A possible use case is one where a Network owner wants to maintain > control of what third-parties do relative to Suppression behavior > on the owner's Network. It is possible that the owner of a > Network could create a registry of Measurement Methods that are > allowable on their Network by third parties that are using a > third-party Controller to measure portions of the owner's > Network. The owner of the Network may determine that within the > set of Measurement Methods, there may be a subset of Measurement > Methods that the Network Owner always wants to be suppressed when > a suppression is sent, and does not want the third-party > Controller to ever override that behavior. > > If the Network owner also owns the Controller, then I can't think > of a good reason to consider this method of dealing with Suppression. > > Charles > > On 6/9/2014 12:19 PM, KEN KO wrote: > > Charles, > > > > Is there a reason to prevent the do-not-suppress flag from > redefining the default suppression behavior suggested for a > particular Measurement Method in a Registry, yet still allow > it to be overridden by the optional suppression fields? Seems > like that would be a needless limitation on the information model. > > > > Ken > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 2:00 PM > *To:* KEN KO; philip.eardley@bt.com > ; lmap@ietf.org > > *Subject:* Re: [lmap] Suppression in framework > > > > Regarding suppression (not communication with the Controller): > My take is that the default suppression behavior can be coded > into the Measurement Method. If there is a possibility that > the default can be overwritten, then an optional field is > added to the Measurement Method. If the Controller wants to > override the default, it must assert the optional override > field when generating the Measurement Task. > > I have not formed an opinion regarding MA communication with > the Controller. > > Charles > > On 6/9/2014 11:05 AM, KEN KO wrote: > > My interpretation of the existing text is that the option > fields already override default behavior. > > > > Given the more general nature of Tasks as you point out, > there may be specific tasks which should simply never be > suppressed, either by default configuration or optional > field. I'm thinking primarily about communication with the > Controller. If we protect that, then suppression of > anything else should be recoverable. And if that is true, > I'm still in favor of the optional fields overriding the > default. > > > > Your thoughts? > > > > *From:*philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > *Sent:* Monday, June 09, 2014 12:56 PM > *To:* KEN KO; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > Over-ride might make it a bit too easy to accidentally > suppress a really crucial Task such as reporting to the > collector or communication with the controller (since > tasks are now general and not just measurement tasks). Or > deliberately by an attacker. > > > > If the controller wants to suppress a task with the > do-not-suppress flag set, then it would either re-does the > task configuration or it updates the schedule > > > > *From:*KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* 09 June 2014 17:49 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > *Subject:* RE: Suppression in framework > > > > I would think that information in the optional Suppress > fields would override the default behavior flag. That is, > if the do-not-suppress flag was set for a given task, yet > a Suppression message specifically listed that same task > (or schedule containing the Task), the task would then be > suppressed and no error would be thrown. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* Monday, June 09, 2014 12:43 PM > *To:* lmap@ietf.org > *Subject:* [lmap] Suppression in framework > > > > So we have agreed to modify suppression so the default > behaviour is that tasks have a Boolean flag which > indicates whether or not a Suppress message will suppress > them. > > Question: what do we want the impact of the flag to be > when we have the more complex, optional Suppress message? > (it lists specific Tasks or Schedules for suppression.) > > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 > > > > > Treating the Boolean flag as meaning "do-not-suppress this > Measurement Task", my proposal is to basically keep the > current text unaltered: > > > > > << Optionally the Suppression information may > > include: > > > > o a set of Measurement Tasks to suppress; the others > are not > > suppressed. For example, this could be useful if a > particular > > Measurement Task is overloading a Measurement Peer. > > > > o a set of Measurement Schedules to suppress; the > others are not > > suppressed. For example, suppose the measurement > system has > > defined two Schedules, one with the most critical > Measurement > > Tasks and the other with less critical ones that > create a lot of > > Active Measurement Traffic, then it may only want to > suppress the > > second. > > > > o a start time, at which suppression begins > > > > o an end time, at which suppression ends > > > > o a demand that the MA ends its on-going Active > Measurement Task(s) > > (and deletes the associated partial Measurement > Result(s)). > > >> > > > > In other words, if the Controller says "Suppress Task > #213" then the MA checks the do-not-suppress flag for Task > #213 and either throws an error or doesn't start this > Task. Similarly, if the Controller says "Suppress Schedule > #49", then the MA checks the do-not-suppress flag for > Tasks in this schedule and either throws an error or > doesn't start any new Tasks in this schedule. > > > > I'll tweak the text to say this (as well as removing the > refs to Active). > > I'll also make clear that the Controller sets the > do-not-suppress flag for a Task (it isn't something that > the MA decides about). > > > > Thanks > > phil > > > > > > > _______________________________________________ > > 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 > > > > > -- > > > > 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 > > > > -- > > 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 -- 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 --------------010406080700070803020803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As soon as I hit send, that thought occurred to me as well, and whether it would be out of scope. 

Your comment on the MA having to test the configuration against what is allowed by the Measurement Method may be more trust worthy from the perspective of the Network owner than the third-party Controller.  The Network owner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Method.

I think I am convinced that maybe this is better handled by an agreement between parties.

Charles

On 6/9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do the right thing, then there seems to be little value in a flag in the Measurement Method that prohibits doing the wrong thing.

 

Perhaps if that is the case, this is better handled by an agreement between parties that would be out of scope for lmap?

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Good point.  Or the Controller can do the configuration manipulation in the creation of the Measurement Task (my preference) so the MA does not have to.  - keep the MA as simple as possible at the expense of the Controller.

Charles

On 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see some utility in that, but it does complicate the MA which would have to test suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method that has been defined a priori such that the Suppression behavior defined in the Measurement Method is not to be over-written, there should be a flag set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppression behavior is permitted to be changed, a flag in the Measurement Method would be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control of what third-parties do relative to Suppression behavior on the owner's Network.  It is possible that the owner of a Network could create a registry of Measurement Methods that are allowable on their Network by third parties that are using  a third-party Controller to measure portions of the owner's Network.  The owner of the Network may determine that within the set of Measurement Methods, there may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is sent, and does not want the third-party Controller to ever override that behavior.

If the Network owner also owns the Controller, then I can't think of a good reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag from redefining the default suppression behavior suggested for a particular Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Measurement Method.  If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method.  If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task.

I have not formed an opinion regarding MA communication with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the option fields already override default behavior.

 

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-suppress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppress fields would override the default behavior flag. That is, if the do-not-suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the more complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurement Task”, my proposal is to basically keep the current text unaltered:

                                                                                     

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to suppress; the others are not

      suppressed.  For example, this could be useful if a particular

      Measurement Task is overloading a Measurement Peer.

 

   o  a set of Measurement Schedules to suppress; the others are not

      suppressed.  For example, suppose the measurement system has

      defined two Schedules, one with the most critical Measurement

      Tasks and the other with less critical ones that create a lot of

      Active Measurement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at which suppression begins

 

   o  an end time, at which suppression ends

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)

      (and deletes the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller says “Suppress Schedule #49”, then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn’t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Active).

I’ll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn’t something that the MA decides about).

 

Thanks

phil






_______________________________________________
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




-- 
 
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



-- 
 
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

-- 

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
--------------010406080700070803020803-- From nobody Mon Jun 9 13:48: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 9738B1A01F5 for ; Mon, 9 Jun 2014 13:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.585 X-Spam-Level: * X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, 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 qCbeX35VYwpb for ; Mon, 9 Jun 2014 13:48:03 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6387D1A01E0 for ; Mon, 9 Jun 2014 13:48:03 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.98,1003,1392181200"; d="scan'208,217";a="352542060" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jun 2014 16:40:19 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.32]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 9 Jun 2014 16:40:34 -0400 From: "Weil, Jason" To: "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Date: Mon, 9 Jun 2014 16:40:33 -0400 Thread-Topic: Mail regarding draft-ietf-lmap-framework-05 Thread-Index: Ac+EIw+wwknhDXzDQleMgblId0J8lw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFBB94012ED3Djasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nqsIeovW2-Lk-tMj5PYAROYz948 Subject: [lmap] Mail regarding draft-ietf-lmap-framework-05 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, 09 Jun 2014 20:48:05 -0000 --_000_CFBB94012ED3Djasonweiltwcablecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Authors and LMAP list, It feels like the WG is near or very close to consensus on the primary poin= ts of discussion regarding version "=9605" of the LMAP Framework document. = The chairs are trying to determine if the document is ready for IESG submis= sion assuming there is one more version coming out in the near future that = includes agreed upon changes or if we need one more round of WGLC. Here is = my view on the recent discussions: -My take is that there is consensus around Suppression in the Framework usi= ng a Boolean flag in the Measurement Task configuration. -Measurement Methods, Tasks, and Roles =96 Are we ok on these definitions o= r is there still more discussion needed here? -My read is that there is consensus on the removal of Active vs. Passive de= finitions. Are there any other major topics that still need to be discussed that I may= have missed in the threads? Thanks Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CFBB94012ED3Djasonweiltwcablecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Authors and LMAP list,

It feels like the WG is near or very close to consensus on the primary= points of discussion regarding version "=9605" of the LMAP Frame= work document. The chairs are trying to determine if the document is ready = for IESG submission assuming there is one more version coming out in the near future that includes agreed upon changes or= if we need one more round of WGLC. Here is my view on the recent discussio= ns:

-My take is that there is consensus around Suppression in the Framewor= k using a Boolean flag in the Measurement Task configuration. 

-Measurement Methods, Tasks, and Roles =96 Are we ok on these definiti= ons or is there still more discussion needed here?

-My read is that there is consensus on the removal of Active vs. Passi= ve definitions. 

Are there any other major topics that still need to be discussed that = I may have missed in the threads?

Thanks

Jason  



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CFBB94012ED3Djasonweiltwcablecom_-- From nobody Mon Jun 9 14:05:49 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 BB25E1A018F for ; Mon, 9 Jun 2014 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FA6eFyVZjId for ; Mon, 9 Jun 2014 14:05:42 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ED41A023B for ; Mon, 9 Jun 2014 14:05:41 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o144.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 5a126935.2b953d62e940.80676.00-578.231439.p01c12o144.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 15:05:41 -0600 (MDT) X-MXL-Hash: 539621a5480ac2fc-b253e1666134490bfc7fdffa7ff660d1ad6e3bc5 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o144.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id ec816935.0.58957.00-106.169709.p01c12o144.mxlogic.net (envelope-from ); Mon, 09 Jun 2014 14:28:00 -0600 (MDT) X-MXL-Hash: 539618d030f2240e-5afc662db43de85f2b5d217f25cb9c1f17e90ee6 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 15:27:58 -0500 From: KEN KO To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74A== Date: Mon, 9 Jun 2014 20:27:57 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> In-Reply-To: <5396161B.3050509@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB777570012exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=cMhuszuN c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=J_N6KFswAAAA:] X-AnalysisOut: [8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=k-ulP1tTMmCpkJhUGnAA] X-AnalysisOut: [:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a] X-AnalysisOut: [=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=lZB815dzVvQA:10 a=Dvn] X-AnalysisOut: [SUQUdWHYA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=RWJ3jZcbI] X-AnalysisOut: [bAJN5bL:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6] X-AnalysisOut: [K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014060933); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/GlOLutTaLzbCXJuIQOo8VNf8L-Q Subject: Re: [lmap] Suppression in 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: Mon, 09 Jun 2014 21:05:46 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB777570012exmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB777570012exmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But if a third party C= ontroller can be trusted to do the right thing, then there seems to be litt= le value in a flag in the Measurement Method that prohibits doing the wrong= thing.

 

Perhaps if that is the= case, this is better handled by an agreement between parties that would be= out of scope for lmap?

 

From: Charles Cook [mailto:c= harles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Good point.  Or the Controller can do the configuration manipulation i= n the creation of the Measurement Task (my preference) so the MA does not h= ave to.  - keep the MA as simple as possible at the expense of the Con= troller.

Charles

On 6/9/2014 1:35 PM, KEN = KO wrote:

OK, thanks. I read it wrong the first time. I can see some utility in = that, but it does complicate the MA which would have to test suppression co= nfiguration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KE= N KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag from redefining= the default suppression behavior suggested for a particular Measurement Me= thod in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would= be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On 6/9/2014 11:05 AM, KE= N KO wrote:

My interpretation of the existing text is that the option fields alre= ady override default behavior.

 

Given the more general nature of Tasks as you point out, there may be= specific tasks which should simply never be suppressed, either by default = configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, the= n suppression of anything else should be recoverable. And if that is true, = I’m still in favor of the optional fields overriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN= .KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppress fields would = override the default behavior flag. That is, if the do-not-suppress flag wa= s set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown.

 

 

From: lmap [mailto:l= map-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement Tasks to= suppress; the others are not

      suppressed.  F= or example, this could be useful if a particular

      Measurement Task is= overloading a Measurement Peer.

 

   o  a set of Measurement Schedule= s to suppress; the others are not

      suppressed.  F= or example, suppose the measurement system has

      defined two Schedul= es, one with the most critical Measurement

      Tasks and the other= with less critical ones that create a lot of

      Active Measurement = Traffic, then it may only want to suppress the

      second.=

 

   o  a start time, at which suppre= ssion begins

 

   o  an end time, at which suppres= sion ends

 

   o  a demand that the MA ends its= on-going Active Measurement Task(s)

      (and deletes the as= sociated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil






__________________________________________=
_____
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:  9=
25.281.0662


charles.cook2@centurylink.com

= 


-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224

Denver, CO  80221


Tel:  303.992.8952  Fax:  9=
25.281.0662


charles.cook2@centurylink.com





-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224

Denver, CO  80221


Tel:  303.992.8952  Fax:  92=
5.281.0662


charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB777570012exmb1corpadtran_-- From nobody Mon Jun 9 14:18: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 331931A020E for ; Mon, 9 Jun 2014 14:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 9_IML4o746am for ; Mon, 9 Jun 2014 14:18:42 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2921A01F5 for ; Mon, 9 Jun 2014 14:18:41 -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) over TLS secured channel with ESMTP id 0b426935.0.2125235.00-2200.5939710.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 09 Jun 2014 21:18:41 +0000 (UTC) X-MXL-Hash: 539624b10adcb7e9-dc757ff4063cfc7e3776eda43a88dc777de2b941 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 s59LIdEP006627; Mon, 9 Jun 2014 17:18:39 -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 s59LIWBo006580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 17:18:34 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 9 Jun 2014 21:18:25 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 17:18:25 -0400 From: "STARK, BARBARA H" To: "Weil, Jason" , "draft-ietf-lmap-framework@tools.ietf.org" , "lmap@ietf.org" Thread-Topic: Mail regarding draft-ietf-lmap-framework-05 Thread-Index: Ac+EIw+wwknhDXzDQleMgblId0J8lwABHtvw Date: Mon, 9 Jun 2014 21:18:25 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE7B8D@GAALPA1MSGUSRBF.ITServices.sbc.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.70.207.101] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE7B8DGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OMyQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=P3TVmq5ppHMA:10 a=ofMgfj31e3cA:10 a=2BBZLY7NTugA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=mEWFgX9Ft36b08zL4LUA:9 a=CjuIK1q_8ugA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=5OKcGE6JX1GkJvVH:21 a=E2o0AnGnvVnjlSpg:21 a=yMh] X-AnalysisOut: [MjlubAAAA:8 a=SSmOFEACAAAA:8 a=qymBFipnO0BIQMCb2MUA:9 a=gK] X-AnalysisOut: [O2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4Au] X-AnalysisOut: [Cg-hUA:10 a=r9NQA45DA5HnXSyC:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/V5SkHCaP4c5ktNZdDnDdXxQN1BI Subject: Re: [lmap] Mail regarding draft-ietf-lmap-framework-05 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, 09 Jun 2014 21:18:44 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE7B8DGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMO the changes that need to be made are fairly extensive. Whether you call= it another round of WGLC or not, we need time to look through the entire -= 06 draft before it gets submitted, to make sure changes were what we though= t they should be. As previously discussed: We need to see the Configuration Protocol that app= eared in -05 disappear, but that should be easy. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason Sent: Monday, June 09, 2014 4:41 PM To: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org Subject: [lmap] Mail regarding draft-ietf-lmap-framework-05 Authors and LMAP list, It feels like the WG is near or very close to consensus on the primary poin= ts of discussion regarding version "-05" of the LMAP Framework document. Th= e chairs are trying to determine if the document is ready for IESG submissi= on assuming there is one more version coming out in the near future that in= cludes agreed upon changes or if we need one more round of WGLC. Here is my= view on the recent discussions: -My take is that there is consensus around Suppression in the Framework usi= ng a Boolean flag in the Measurement Task configuration. -Measurement Methods, Tasks, and Roles - Are we ok on these definitions or = is there still more discussion needed here? -My read is that there is consensus on the removal of Active vs. Passive de= finitions. Are there any other major topics that still need to be discussed that I may= have missed in the threads? Thanks Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2D09D61DDFA73D4C884805CC7865E61130DE7B8DGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMO the changes that need= to be made are fairly extensive. Whether you call it another round of WGLC= or not, we need time to look through the entire -06 draft before it gets submitted, to make sure changes were what we thought they s= hould be.

As previously discussed: = We need to see the Configuration Protocol that appeared in -05 disappear, b= ut that should be easy.

Barbara=

 <= /p>

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason
Sent: Monday, June 09, 2014 4:41 PM
To: draft-ietf-lmap-framework@tools.ietf.org; lmap@ietf.org
Subject: [lmap] Mail regarding draft-ietf-lmap-framework-05

 

Authors and LMAP list,=

 

It feels like the WG is nea= r or very close to consensus on the primary points of discussion regarding = version "–05" of the LMAP Framework document. The chairs are trying to determine if the document is ready for IESG submission assum= ing there is one more version coming out in the near future that includes a= greed upon changes or if we need one more round of WGLC. Here is my view on= the recent discussions:

 

-My take is that there is c= onsensus around Suppression in the Framework using a Boolean flag in the Me= asurement Task configuration. 

 

-Measurement Methods, Tasks= , and Roles – Are we ok on these definitions or is there still more d= iscussion needed here?

 

-My read is that there is c= onsensus on the removal of Active vs. Passive definitions. =

 

Are there any other major t= opics that still need to be discussed that I may have missed in the threads= ?

 

Thanks

 

Jason  

 

 

 

This E-mail and any of its atta= chments may contain Time Warner Cable proprietary information, which is pri= vileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the in= dividual or entity to which it is addressed. If you are not the intended re= cipient of this E-mail, you are hereby notified that any dissemination, dis= tribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly = prohibited and may be unlawful. If you have received this E-mail in error, = please notify the sender immediately and permanently delete the original an= d any copy of this E-mail and any printout.

--_000_2D09D61DDFA73D4C884805CC7865E61130DE7B8DGAALPA1MSGUSRBF_-- From nobody Mon Jun 9 14:34: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 168CF1A0339 for ; Mon, 9 Jun 2014 14:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 eN3UxPwfuhuS for ; Mon, 9 Jun 2014 14:34:29 -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 50DD31A0331 for ; Mon, 9 Jun 2014 14:34:29 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id B90EE120930; Mon, 9 Jun 2014 17:37:15 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id D1E11F03A8; Mon, 9 Jun 2014 17:34:27 -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; Mon, 9 Jun 2014 17:34:27 -0400 From: "MORTON, ALFRED C (AL)" To: KEN KO , "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Date: Mon, 9 Jun 2014 17:34:25 -0400 Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/wgABnHbA= Message-ID: <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.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/QIXI4XiMLr_0DtRyMJJE4MRV0hw Subject: Re: [lmap] Measurement Methods and Tasks 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, 09 Jun 2014 21:34:31 -0000 Charles, When you say,=20 "...the Measurement Method defines all possible roles." it may be true for the details of making measurements. But I think there are other roles which are equally=20 important to establish - measurement control protocol roles and test session protocol roles. One of the example figures in the Framework covers OWAMP: +----------------+ OWAMP +----------------+ ^ | OWAMP |<--control--->| MP: | | | control-client |>test-traffic>| OWAMP server & | IPPM | fetch-client & |<----fetch----| session-rec'ver| Scope | session-sender | | | | | | +----------------+ | ...|................|....................................v... | LMAP interface | ^ +----------------+ | The protocol roles, such as control-client <---> server, need to be specified and communicated from the LMAP MA to the control-client interface, the device on the left above is not a session-sender by default, for example. In the Measurement Methods written by IPPM, there will=20 typically be the roles of Source and Destination, and these are the only set of roles that would normally appear. This is the material that will appear in the Registry for Performance metrics - but there won't be any discussion of OWAMP-specifics, just packet measurement processes. So, both Protocol roles and Measurement roles are needed, and only one can be found in the registry. regards, Al > -----Original Message----- > From: KEN KO [mailto:KEN.KO@adtran.com] > Sent: Monday, June 09, 2014 2:12 PM > To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON, ALFRED = C > (AL); STARK, BARBARA H; lmap@ietf.org > Subject: RE: [lmap] Measurement Methods and Tasks >=20 > Yes, that is how I interpret it. >=20 > -----Original Message----- > From: Charles Cook [mailto:charles.cook2@centurylink.com] > Sent: Monday, June 09, 2014 1:50 PM > To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com; > lmap@ietf.org > Subject: Re: [lmap] Measurement Methods and Tasks >=20 > If I understand correctly, the Measurement Method defines all the possibl= e > roles. The Measurement Task generated by the Control sets an Input > parameter that selects the role the MA is to perform. >=20 > Charles >=20 > On 6/9/2014 10:56 AM, KEN KO wrote: > >> ... it's probably more consistent with ippm for it to be a registry > >> of Methods. So then the ***Measurement Task Configuration*** needs an > >> Input Parameter (or some other kind of configuration option) to > >> choose between different roles (client, server...) > > With that one (hopefully minor) tweak, +1 > > >=20 > -- >=20 > 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 Mon Jun 9 16:03: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 61DB61A01EB for ; Mon, 9 Jun 2014 16:03:11 -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 sovrMl24DiIR for ; Mon, 9 Jun 2014 16:03:09 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9481A0053 for ; Mon, 9 Jun 2014 16:03:09 -0700 (PDT) Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s59N31TP000151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2014 18:03:02 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id F38AC1E0060; Mon, 9 Jun 2014 18:02:55 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 34F0D1E0088; Mon, 9 Jun 2014 18:02:54 -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 s59N2rxY002789; Mon, 9 Jun 2014 17:02:53 -0600 (MDT) Received: from [10.183.200.27] (x1069818.dhcp.intranet [10.183.200.27]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s59N2qDD002750; Mon, 9 Jun 2014 17:02:52 -0600 (MDT) Message-ID: <53963D1D.4030208@centurylink.com> Date: Mon, 09 Jun 2014 17:02:53 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , KEN KO , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> X-Enigmail-Version: 1.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/OFJspWofjqh3hWdgNmZKEvobhD8 Subject: Re: [lmap] Measurement Methods and Tasks 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: Mon, 09 Jun 2014 23:03:11 -0000 I agree. My comment was only addressing the details of making measurements. Charles On 6/9/2014 3:34 PM, MORTON, ALFRED C (AL) wrote: > Charles, > > When you say, > "...the Measurement Method defines all possible roles." > it may be true for the details of making measurements. > But I think there are other roles which are equally > important to establish - measurement control protocol roles > and test session protocol roles. > > One of the example figures in the Framework covers OWAMP: > > +----------------+ OWAMP +----------------+ ^ > | OWAMP |<--control--->| MP: | | > | control-client |>test-traffic>| OWAMP server & | IPPM > | fetch-client & |<----fetch----| session-rec'ver| Scope > | session-sender | | | | > | | +----------------+ | > ...|................|....................................v... > | LMAP interface | ^ > +----------------+ | > > The protocol roles, such as control-client <---> server, > need to be specified and communicated from the LMAP MA > to the control-client interface, the device on the left > above is not a session-sender by default, for example. > > In the Measurement Methods written by IPPM, there will > typically be the roles of Source and Destination, and these > are the only set of roles that would normally appear. > This is the material that will appear in the Registry for > Performance metrics - but there won't be any discussion > of OWAMP-specifics, just packet measurement processes. > > So, both Protocol roles and Measurement roles are needed, > and only one can be found in the registry. > > regards, > Al > >> -----Original Message----- >> From: KEN KO [mailto:KEN.KO@adtran.com] >> Sent: Monday, June 09, 2014 2:12 PM >> To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON, ALFRED C >> (AL); STARK, BARBARA H; lmap@ietf.org >> Subject: RE: [lmap] Measurement Methods and Tasks >> >> Yes, that is how I interpret it. >> >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: Monday, June 09, 2014 1:50 PM >> To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com; >> lmap@ietf.org >> Subject: Re: [lmap] Measurement Methods and Tasks >> >> If I understand correctly, the Measurement Method defines all the possible >> roles. The Measurement Task generated by the Control sets an Input >> parameter that selects the role the MA is to perform. >> >> Charles >> >> On 6/9/2014 10:56 AM, KEN KO wrote: >>>> ... it's probably more consistent with ippm for it to be a registry >>>> of Methods. So then the ***Measurement Task Configuration*** needs an >>>> Input Parameter (or some other kind of configuration option) to >>>> choose between different roles (client, server...) >>> With that one (hopefully minor) tweak, +1 >>> >> -- >> >> 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 -- 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 Jun 10 01:21:35 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 93BA01A0286 for ; Tue, 10 Jun 2014 01:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytoOBpf8MSOz for ; Tue, 10 Jun 2014 01:21:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669971A0011 for ; Tue, 10 Jun 2014 01:21:25 -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.181.6; Tue, 10 Jun 2014 09:17:12 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Tue, 10 Jun 2014 09:21:02 +0100 From: To: , , Date: Tue, 10 Jun 2014 09:21:01 +0100 Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+EI2x8Ds7HUr2RTGyzAZ08822HsgAX1XAQ Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> In-Reply-To: <53961C47.7040708@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: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3408EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/97tpxCrmxfB5KALCGwY_fPD8bwo Subject: Re: [lmap] Suppression in 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: Tue, 10 Jun 2014 08:21:31 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3408EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 -- 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 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3408EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= My take is that the do-not-suppress flag should not be defined in the Mea= surement Method. The controller should be able to set it. for some operator= s of measurement systems a particular method may be critical, for some it m= ay be highly optional.

&n= bsp;

Allowing the optional msg to ov= er-ride the do-not-suppress flag – I don’t think this is very c= lean. There are some tasks (communication with controller) that would need = to be marked as ‘really do not suppress, even if the optional msg say= s so’. Perhaps also it would mean that the normal suppress and option= al suppress msgs would have to be processed differently.<= /p>

 

=  

 

Fr= om: Charles Cook [mailto:charles.cook2@cen= turylink.com]
Sent: 09 June 2014 21:43
To: KEN KO; Ear= dley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] Suppress= ion in framework

 

As soo= n as I hit send, that thought occurred to me as well, and whether it would = be out of scope. 

Your comment on the MA having to test the co= nfiguration against what is allowed by the Measurement Method may be more t= rust worthy from the perspective of the Network owner than the third-party = Controller.  The Network owner certainly would not be precluded from d= esigning its MAs to perform such a test against the Measurement Method.
I think I am convinced that maybe this is better handled by an agreeme= nt between parties.

Charles

= On 6/9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do the rig= ht thing, then there seems to be little value in a flag in the Measurement = Method that prohibits doing the wrong thing.

 

Perhaps if that is the case,= this is better handled by an agreement between parties that would be out o= f scope for lmap?

 

From: Charl= es Cook [mailto:charles.co= ok2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
= To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subjec= t: Re: [lmap] Suppression in framework

 

Good point.  Or the Controller can do= the configuration manipulation in the creation of the Measurement Task (my= preference) so the MA does not have to.  - keep the MA as simple as p= ossible at the expense of the Controller.

Charles

On 6/9/2014 1:35 PM, KEN= KO wrote:

OK, thanks. I read it wrong the first time. I can see s= ome utility in that, but it does complicate the MA which would have to test= suppression configuration in the Task against what is allowed by the Measu= rement Method.

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm'>

From:= Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Monday,= June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@bt.com; lmap= @ietf.org
Subject: Re: [lmap] Suppression in framework=

 

Ken,

I'm = not sure I follow your question.  If there is a Measurement Method tha= t has been defined a priori such that the Suppression behavior defined in t= he Measurement Method is not to be over-written, there should be a flag set= to indicate that the Suppression behavior cannot be modified.  In oth= er words, if the defined suppression behavior is permitted to be changed, a= flag in the Measurement Method would be set to Suppression_Behavior_Modifi= able : True.

A possible use case is one where a Network owner wants = to maintain control of what third-parties do relative to Suppression behavi= or on the owner's Network.  It is possible that the owner of a Network= could create a registry of Measurement Methods that are allowable on their= Network by third parties that are using  a third-party Controller to = measure portions of the owner's Network.  The owner of the Network may= determine that within the set of Measurement Methods, there may be a subse= t of Measurement Methods that the Network Owner always wants to be suppress= ed when a suppression is sent, and does not want the third-party Controller= to ever override that behavior.

If the Network owner also owns the = Controller, then I can't think of a good reason to consider this method of = dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN KO wrote:

Charles,

 

I= s there a reason to prevent the do-not-suppress flag from redefining the de= fault suppression behavior suggested for a particular Measurement Method in= a Registry, yet still allow it to be overridden by the optional suppressio= n fields? Seems like that would be a needless limitation on the information= model.

 

Ken

 

From: Charles Cook [mailto:ch= arles.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:0= 0 PM
To: KEN KO; philip.= eardley@bt.com; lmap@ietf.org
<= b>Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not commu= nication with the Controller):
My take is that the default suppression b= ehavior can be coded into the Measurement Method.  If there is a possi= bility that the default can be overwritten, then an optional field is added= to the Measurement Method.  If the Controller wants to override the d= efault, it must assert the optional override field when generating the Meas= urement Task.

I have not formed an opinion regarding MA communicatio= n with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the option fields alread= y override default behavior.

 =

Given the more general nature of Tasks as you point out, th= ere may be specific tasks which should simply never be suppressed, either b= y default configuration or optional field. I’m thinking primarily abo= ut communication with the Controller. If we protect that, then suppression = of anything else should be recoverable. And if that is true, I’m stil= l in favor of the optional fields overriding the default.=

 

Your thoughts?

 

From: p= hilip.eardley@bt.com [mailto:p= hilip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PMTo: KEN KO; lmap@ietf.org
= Subject: RE: Suppression in framework

 

=

Over-ride might make i= t a bit too easy to accidentally suppress a really crucial Task such as rep= orting to the collector or communication with the controller (since tasks a= re now general and not just measurement tasks).  Or deliberately by an= attacker.

 

If the controller wants to suppress a task with the do-not= -suppress flag set, then it would either re-does the task configuration or = it updates the schedule

 

<= p class=3DMsoNormal style=3D'margin-left:144.0pt'>From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 J= une 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: Suppression in framew= ork

 

I would think that information in t= he optional Suppress fields would override the default behavior flag. That = is, if the do-not-suppress flag was set for a given task, yet a Suppression= message specifically listed that same task (or schedule containing the Tas= k), the task would then be suppressed and no error would be thrown. =

 

 

From: lmap [mailto:lmap-bounces@ietf.o= rg] On Behalf Of philip= .eardley@bt.com
Sent: Monday, June 09, 2014 12:43 PM
To= : lmap@ietf.org
Subject:= [lmap] Suppression in framework

 

So we have agreed to modify suppression so t= he default behaviour is that tasks have a Boolean flag which indicates whet= her or not a Suppress message will suppress them.

Question: what do we want the impact = of the flag to be when we have the more complex, optional Suppress message?= (it lists specific Tasks or Schedules for suppression.)  =

http://tools.ietf.org/= html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “d= o-not-suppress this Measurement Task”, my proposal is to basically ke= ep the current text unaltered:

         &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             <= /span>

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to = suppress; the others are not

  &n= bsp;   suppressed.  For example, this could be useful if a p= articular

      Me= asurement Task is overloading a Measurement Peer.

 

   o  a set of= Measurement Schedules to suppress; the others are not

      suppressed.  For example, s= uppose the measurement system has

 &nb= sp;    defined two Schedules, one with the most critical Mea= surement

      Tas= ks and the other with less critical ones that create a lot of

      Active Measurement Traffi= c, then it may only want to suppress the

=       second.

&nbs= p;

   o  a start time, at wh= ich suppression begins

 

   o  an end time, at which suppression e= nds

 

=    o  a demand that the MA ends its on-going Active Measurem= ent Task(s)

      = (and deletes the associated partial Measurement Result(s)).

>> <= /o:p>

 =

In other words, if the Contro= ller says “Suppress Task #213” then the MA checks the do-not-su= ppress flag for Task #213 and either throws an error or doesn’t start= this Task. Similarly, if the Controller says “Suppress Schedule #49&= #8221;, then the MA checks the do-not-suppress flag for Tasks in this sched= ule and either throws an error or doesn’t start any new Tasks in this= schedule.

&= nbsp;

I̵= 7;ll tweak the text to say this (as well as removing the refs to Active).

I’ll al= so make clear that the Controller sets the do-not-suppress flag for a Task = (it isn’t something that the MA decides about).

=

 

Thanks

phil







______________________=
_________________________
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
T=
el:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com





-- 
 
Char=
les Cook 
Principal Archi=
tect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221<=
/pre>
Tel:  303.992.8952  Fax:&n=
bsp; 925.281.0662
charles.cook2@centurylink.com=





-- 
 
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
<=
p class=3DMsoNormal>

-- 
 
Charles Cook 
Principal A=
rchitect
Network
5325 Zuni Street=
; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centurylin= k.com
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3408EMV67UKRDdoma_-- From nobody Tue Jun 10 01:27:27 2014 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA01A017E for ; Tue, 10 Jun 2014 01:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1Vz2yM_kS57 for ; Tue, 10 Jun 2014 01:27:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6231A0010 for ; Tue, 10 Jun 2014 01:27:19 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:27:26 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.235]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 10 Jun 2014 09:26:38 +0100 From: To: , , , Date: Tue, 10 Jun 2014 09:26:37 +0100 Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+EI2x8Ds7HUr2RTGyzAZ08822HsgAX1XAQAACe6FA= Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_ED51D9282D1D3942B9438CA8F3372EB72D9D9BA4B2EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/eBkwhf44cHMygPxhZRvGlyaOk4I Subject: Re: [lmap] Suppression in 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: Tue, 10 Jun 2014 08:27:25 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72D9D9BA4B2EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The last bit is important - when we just send a basic suppress message (i.e= . default suppress everything) then this DOESN'T over-ride the flags. I wou= ldn't be in favour of reversing this when selected tasks/schedules are list= ed. I think this would create confusion. Also I'm in favour of not over-riding to give a bit more accidental protect= ion to critical tasks, such as communicating with the Controller. Remember = if we do want to over-ride any flags, the controller is free to either chan= ge those flags or remove the task from the schedules. So we always have the= ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KEN.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 -- 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 --_000_ED51D9282D1D3942B9438CA8F3372EB72D9D9BA4B2EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= The last bit is important – when we jus= t send a basic suppress message (i.e. default suppress everything) then thi= s DOESN’T over-ride the flags. I wouldn’t be in favour of rever= sing this when selected tasks/schedules are listed. I think this would crea= te confusion.

 

Also I’m in favour of not over-riding to give a bit mo= re accidental protection to critical tasks, such as communicating with the = Controller. Remember if we do want to over-ride any flags, the controller i= s free to either change those flags or remove the task from the schedules. = So we always have the ability to switch off any task.

=

 =

Trevor.

 

 =

From: lmap [mailto:lmap-bounces@i= etf.org] On Behalf Of philip.eardley@bt.com
Sent: 10 June = 2014 09:21
To: charles.cook2@centurylink.com; KEN.KO@adtran.com; = lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My take is that the do-not-suppress flag should not be def= ined in the Measurement Method. The controller should be able to set it. fo= r some operators of measurement systems a particular method may be critical= , for some it may be highly optional.

 

Allowing the opt= ional msg to over-ride the do-not-suppress flag – I don’t think= this is very clean. There are some tasks (communication with controller) t= hat would need to be marked as ‘really do not suppress, even if the o= ptional msg says so’. Perhaps also it would mean that the normal supp= ress and optional suppress msgs would have to be processed differently.

 

 

&n= bsp;

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,= PL,Philip,TUB8 R; lmap@ietf.org
= Subject: Re: [lmap] Suppression in framework

 

As soon as I hit send, that thought occurred to m= e as well, and whether it would be out of scope. 

Your comment= on the MA having to test the configuration against what is allowed by the = Measurement Method may be more trust worthy from the perspective of the Net= work owner than the third-party Controller.  The Network owner certain= ly would not be precluded from designing its MAs to perform such a test aga= inst the Measurement Method.

I think I am convinced that maybe this= is better handled by an agreement between parties.

Charles

On 6/9/2014 2:27 PM, KEN KO wrote:

But if a third party Control= ler can be trusted to do the right thing, then there seems to be little val= ue in a flag in the Measurement Method that prohibits doing the wrong thing= .

&= nbsp;

Perhaps if that is the case, this is better handled by an agreement betw= een parties that would be out of scope for lmap?

 

<= div>

= From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: Mo= nday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Good point.=   Or the Controller can do the configuration manipulation in the creat= ion of the Measurement Task (my preference) so the MA does not have to.&nbs= p; - keep the MA as simple as possible at the expense of the Controller.
Charles

On 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wr= ong the first time. I can see some utility in that, but it does complicate = the MA which would have to test suppression configuration in the Task again= st what is allowed by the Measurement Method.

&nb= sp;

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN K= O; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap= ] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If = there is a Measurement Method that has been defined a priori such that the = Suppression behavior defined in the Measurement Method is not to be over-wr= itten, there should be a flag set to indicate that the Suppression behavior= cannot be modified.  In other words, if the defined suppression behav= ior is permitted to be changed, a flag in the Measurement Method would be s= et to Suppression_Behavior_Modifiable : True.

A possible use case is= one where a Network owner wants to maintain control of what third-parties = do relative to Suppression behavior on the owner's Network.  It is pos= sible that the owner of a Network could create a registry of Measurement Me= thods that are allowable on their Network by third parties that are using&n= bsp; a third-party Controller to measure portions of the owner's Network.&n= bsp; The owner of the Network may determine that within the set of Measurem= ent Methods, there may be a subset of Measurement Methods that the Network = Owner always wants to be suppressed when a suppression is sent, and does no= t want the third-party Controller to ever override that behavior.

If= the Network owner also owns the Controller, then I can't think of a good r= eason to consider this method of dealing with Suppression.

Charles <= o:p>

On 6/9= /2014 12:19 PM, KEN KO wrote:

Charles,

&= nbsp;

Is there a reason to prevent the do-not-sup= press flag from redefining the default suppression behavior suggested for a= particular Measurement Method in a Registry, yet still allow it to be over= ridden by the optional suppression fields? Seems like that would be a needl= ess limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Se= nt: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in f= ramework

 

Regarding suppression (not communication with the Controller):
My take = is that the default suppression behavior can be coded into the Measurement = Method.  If there is a possibility that the default can be overwritten= , then an optional field is added to the Measurement Method.  If the C= ontroller wants to override the default, it must assert the optional overri= de field when generating the Measurement Task.

I have not formed an = opinion regarding MA communication with the Controller.

Charles=

On 6/9/20= 14 11:05 AM, KEN KO wrote:

My interpretation of the existing text= is that the option fields already override default behavior. <= /o:p>

 

Given the more general nat= ure of Tasks as you point out, there may be specific tasks which should sim= ply never be suppressed, either by default configuration or optional field.= I’m thinking primarily about communication with the Controller. If w= e protect that, then suppression of anything else should be recoverable. An= d if that is true, I’m still in favor of the optional fields overridi= ng the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in frame= work

 

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication= with the controller (since tasks are now general and not just measurement = tasks).  Or deliberately by an attacker.

 

<= p class=3DMsoNormal style=3D'margin-left:144.0pt'>If the controller wants= to suppress a task with the do-not-suppress flag set, then it would either= re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtr= an.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Ph= ilip,TUB8 R; lmap@ietf.org
Subje= ct: RE: Suppression in framework

 

I = would think that information in the optional Suppress fields would override= the default behavior flag. That is, if the do-not-suppress flag was set fo= r a given task, yet a Suppression message specifically listed that same tas= k (or schedule containing the Task), the task would then be suppressed and = no error would be thrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Monda= y, June 09, 2014 12:43 PM
To: lm= ap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have = agreed to modify suppression so the default behaviour is that tasks have a = Boolean flag which indicates whether or not a Suppress message will suppres= s them.

Ques= tion: what do we want the impact of the flag to be when we have the more co= mplex, optional Suppress message? (it lists specific Tasks or Schedules for= suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15<= /a>

 <= /span>

Treating the= Boolean flag as meaning “do-not-suppress this Measurement Task”= ;, my proposal is to basically keep the current text unaltered:=

    = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;      

<< Optionally the Suppression information=
 may

   include:

 

   o&nbs= p; a set of Measurement Tasks to suppress; the others are not

      suppressed.  For exa= mple, this could be useful if a particular

=       Measurement Task is overloading a Measuremen= t Peer.

 

   o  a set of Measurement Schedules to suppress; the ot= hers are not

     = suppressed.  For example, suppose the measurement system has

      defined two Schedule= s, one with the most critical Measurement

=       Tasks and the other with less critical ones = that create a lot of

   &nbs= p;  Active Measurement Traffic, then it may only want to suppress the<= /span>

      second.

 

 &n= bsp; o  a start time, at which suppression begins

 

   o  an = end time, at which suppression ends

 <= /span>

   o  a demand that the MA e= nds its on-going Active Measurement Task(s)

>> 

 

In other words, if the Controller says “Suppress Task #213”= ; then the MA checks the do-not-suppress flag for Task #213 and either thro= ws an error or doesn’t start this Task. Similarly, if the Controller = says “Suppress Schedule #49”, then the MA checks the do-not-sup= press flag for Tasks in this schedule and either throws an error or doesn&#= 8217;t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well= as removing the refs to Active).

I’ll also make clear that the Controller sets t= he do-not-suppress flag for a Task (it isn’t something that the MA de= cides about).

 

Tha= nks

phil





________=
_______________________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap<=
/pre>




=

-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni =
Street; Suite 224
Denver=
, CO  80221
Tel:&nb=
sp; 303.992.8952  Fax:  925.281.0662
c=
harles.cook2@centurylink.com



-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662<=
/o:p>
charles.cook2@centurylink.com


-- 
 
Cha=
rles Cook 
Principal Arch=
itect
Network<=
/pre>
5325 Zuni Street; Suite 224
Denver, CO  80221=

Tel:  303.992.8952  Fax:&=
nbsp; 925.281.0662
charles.cook2@centurylink.com
 
-- 
 
Charles Cook 
Principal Architect<=
/o:p>
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  3=
03.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com=
= --_000_ED51D9282D1D3942B9438CA8F3372EB72D9D9BA4B2EMV64UKRDdoma_-- From nobody Tue Jun 10 01:45: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 8D8871A0354 for ; Tue, 10 Jun 2014 01:44:58 -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 IUnH6iy3HP86 for ; Tue, 10 Jun 2014 01:44:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB4D1A0343 for ; Tue, 10 Jun 2014 01:44:56 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 09:40:44 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 10 Jun 2014 09:44:19 +0100 From: To: , , , , Date: Tue, 10 Jun 2014 09:44:17 +0100 Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/wgABnHbCAABPXYA== Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.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/2hNg7HI8wdDMTknDYlXc5by7HXM Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 08:44:58 -0000 So in terms of the text in the section about Control Protocol - Instruction= . Finding it quite tricky to get the right words... Al, haven't managed to capture your point about protocol roles. << The Instruction defines information with the following aims ([I-D.ietf-lmap-information-model] defines the consequent list of information elements): o the Measurement Task configurations, each of which needs: * the Metric, specified as a URI to a registry entry; it includes the specification of a Measurement Method. The registry could be defined by the IETF [I-D.manyfolks-ippm-metric-registry], locally by the operator of the measurement system or perhaps by another standards organisation. [new] * the Measurement Method role. For some Measurement Methods, differe= nt parties play different roles; for example (figure A3 in the Appendix) an= iperf sender and receiver. Depending on how the registry is defined, the d= ifferent roles could be different Measurement Methods or the same Measureme= nt Method with different Input Parameters.=20 * any Input Parameters that need to be set for the Measurement Method, such as the address of a Measurement Peer (or other Measurement Agent) that may be involved in a Measurement Task [above bullet tweaked to remove 'Active'] * if the device with the MA has multiple interfaces, then the interface to use (if not defined, then the default interface is used) >> In the appendix, add to the para about figure A3 <> Maybe something could be added about A2, covering different protocol roles?= (although note that the A2 example involves only one MA, so less clear it = really involves two Measurement Method roles) Thanks phil > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: 09 June 2014 22:34 > To: KEN KO; charles.cook2@centurylink.com; Eardley,PL,Philip,TUB8 R; > STARK, BARBARA H; lmap@ietf.org > Subject: RE: [lmap] Measurement Methods and Tasks >=20 > Charles, >=20 > When you say, > "...the Measurement Method defines all possible roles." > it may be true for the details of making measurements. > But I think there are other roles which are equally important to > establish - measurement control protocol roles and test session > protocol roles. >=20 > One of the example figures in the Framework covers OWAMP: >=20 > +----------------+ OWAMP +----------------+ ^ > | OWAMP |<--control--->| MP: | | > | control-client |>test-traffic>| OWAMP server & | IPPM > | fetch-client & |<----fetch----| session-rec'ver| Scope > | session-sender | | | | > | | +----------------+ | > ...|................|....................................v... > | LMAP interface | ^ > +----------------+ | >=20 > The protocol roles, such as control-client <---> server, need to be > specified and communicated from the LMAP MA to the control-client > interface, the device on the left above is not a session-sender by > default, for example. >=20 > In the Measurement Methods written by IPPM, there will typically be the > roles of Source and Destination, and these are the only set of roles > that would normally appear. > This is the material that will appear in the Registry for Performance > metrics - but there won't be any discussion of OWAMP-specifics, just > packet measurement processes. >=20 > So, both Protocol roles and Measurement roles are needed, and only one > can be found in the registry. >=20 > regards, > Al >=20 > > -----Original Message----- > > From: KEN KO [mailto:KEN.KO@adtran.com] > > Sent: Monday, June 09, 2014 2:12 PM > > To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON, > > ALFRED C (AL); STARK, BARBARA H; lmap@ietf.org > > Subject: RE: [lmap] Measurement Methods and Tasks > > > > Yes, that is how I interpret it. > > > > -----Original Message----- > > From: Charles Cook [mailto:charles.cook2@centurylink.com] > > Sent: Monday, June 09, 2014 1:50 PM > > To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com; > > lmap@ietf.org > > Subject: Re: [lmap] Measurement Methods and Tasks > > > > If I understand correctly, the Measurement Method defines all the > > possible roles. The Measurement Task generated by the Control sets > an > > Input parameter that selects the role the MA is to perform. > > > > Charles > > > > On 6/9/2014 10:56 AM, KEN KO wrote: > > >> ... it's probably more consistent with ippm for it to be a > registry > > >> of Methods. So then the ***Measurement Task Configuration*** needs > > >> an Input Parameter (or some other kind of configuration option) to > > >> choose between different roles (client, server...) > > > With that one (hopefully minor) tweak, +1 > > > > > > > -- > > > > 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 Jun 10 05:54: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 A5CEF1A01C9 for ; Tue, 10 Jun 2014 05:54:20 -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 zeopGzumMIUC for ; Tue, 10 Jun 2014 05:54:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEB11A0123 for ; Tue, 10 Jun 2014 05:54:17 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.bt.com (10.187.98.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 13:54:20 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 10 Jun 2014 13:54:15 +0100 From: To: , Date: Tue, 10 Jun 2014 13:54:14 +0100 Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwDHH2Jg Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.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/D_o0c-zkxzUEB9i34HFM-_Ofm1U Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 12:54:20 -0000 Can I suggest a mod: Measurement Task: The action performed by a particular Measurement Agent th= at consists of the single operation of the Measurement Method at a particul= ar time and with all its Input Parameters set to specific values. =20 Ie if a Method involves two MAs then a particular Task is what one MA does = (and the other MA needs to be instructed with another Task) Ps Barbara - thanks for these clarifications phil=20 =20 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > Sent: 06 June 2014 14:49 > To: lmap@ietf.org > Subject: [lmap] Measurement Methods and Tasks >=20 > Now that it appears we may have resolved the LMAP active/passive > debates (by getting rid of the words) and ambiguity around "which tasks > get suppressed by default", maybe we could agree on what Measurement > Method and Measurement Task are? >=20 > I'd like to propose: > Measurement Method: The process for assessing the value of a Metric; > the process of measuring some performance or reliability parameter > associated with the transfer of traffic; where this process involves > multiple MAs or MPs, each may perform different roles. >=20 > Measurement Task: The act that consists of the single operation of > a Measurement Method role at a particular time and with all its > Input > Parameters set to specific values. >=20 > Measurement Method role is not a defined term, but can be used to > express the capability implemented within a MA (or MP) that allows it > to participate in a Measurement Method. I see that various ippm RFCs > use the word "role" in this way, including OWAMP and TWAMP. >=20 > If there is a need to talk about an instance of executing a Measurement > Method, this could be called a Measurement Method instance. Again, > without definition as a formal term. >=20 > There exist several instances of "Measurement Method" that would need > to become "Measurement Method role". For example: > "A Measurement Task is a specific instantiation of a Measurement > Method role." >=20 > Capabilities: Information about the performance measurement > capabilities of the MA, in particular the Measurement Method roles > that it > can perform, and the device hosting the MA, for example its > interface > type and speed, but not dynamic information. >=20 > "the Measurement Method roles that the MA supports" >=20 > But most discussion of Measurement Method in framework is of the > Measurement Method and not the Measurement Method role. >=20 > There is one instance where "Measurement Task capability" is used in > the same sense as a Measurement Method role: "...Measurement Agents may > come from > different vendors, be in wired and wireless networks, have > different Measurement Task capabilities and be on devices with > IPv4 or IPv6 addresses." >=20 > I found one instance where I question the use of "Measurement Task" and > wonder if it should be "Measurement Method": > "Some Measurement Tasks involve several MAs acting in a coordinated > fashion." >=20 > In my scan of framework, I couldn't find a place where I thought > Measurement Task was used to mean a Measurement Method instance. > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Tue Jun 10 05:55: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 A0A031A0552 for ; Tue, 10 Jun 2014 05:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf8_LITd6dzc for ; Tue, 10 Jun 2014 05:55:30 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B911A00FE for ; Tue, 10 Jun 2014 05:55:29 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o143.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 14007935.2b0e23804940.84669.00-590.218544.p01c12o143.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 06:55:29 -0600 (MDT) X-MXL-Hash: 539700415a2e9627-9f77aad400c09ed041a8ac6e652691cdecae02d5 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o143.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id edff6935.0.83609.00-247.215771.p01c12o143.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 06:53:55 -0600 (MDT) X-MXL-Hash: 5396ffe31f6fe747-3b601376c1de684f091c648d0292c8e688ba988d Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 07:53:49 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpg Date: Tue, 10 Jun 2014 12:53:48 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB7775706ABexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=XcAHzeJ5 c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=e9qsufxtAAAA:] X-AnalysisOut: [8 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 a=Y7DWF4qTjZpIv50UAqIA] X-AnalysisOut: [:9 a=tg6E3wB9P9GzJY1g:21 a=UOu2OIb-h144Yz9Y:21 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a=W1qU_X6G3J8A:] X-AnalysisOut: [10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a] X-AnalysisOut: [=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=J2Yyjv77Qd7Wy6dG:21 a=8] X-AnalysisOut: [nTwyfgjxZdRrzFP:21 a=qXEcUrczTbT8rcC_:21 a=gKO2Hq4RSVkA:10] X-AnalysisOut: [ a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061007); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2X5qzhz0ZfrFF_ieV-kp5LXv1Mo Subject: Re: [lmap] Suppression in 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: Tue, 10 Jun 2014 12:55:36 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7775706ABexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems that we are expressing two different interpretations of this flag,= and we need to converge on one. Definition "A" What I proposed is a flag that *defines* the default suppression behavior o= f a task, e.g. in response to a basic suppress message. In that context, Tr= evor's first sentence has no meaning because the flags themselves define th= e response to a basic suppress message - that is, there is nothing to overr= ide. The MA interprets the basic suppression message as "do what the flag s= ays" for each Task. If the flag is cleared, the task is suppressed by defau= lt (using Phil's do-not-suppress polarity - I would reverse it, but that's = a minor point). If the flag is set, the task is not suppressed by default. Definition "B" Trevor and Phil, I think (please correct me if this is wrong) you are inter= preting these flags as identifying exceptions to predefined default suppres= sion behavior. That is, if the flag is not set the suppression behavior con= forms to a fixed definition, but if the flag is set the Task is not suppres= sed. This is a one-way flag - there is no way to use it to change the defau= lt behavior of a Task that is not normally suppressed. Is this understandin= g of your interpretation correct? For what it is worth, I favor "A". I proposed it to resolve any ambiguity i= n the definition of Active vs. Passive as it applies to default suppression= behavior while allowing each operator to define that behavior on their own= terms. "B" doesn't achieve either of those goals. Having said all that, I agree with you that communication with the Controll= er should never be suppressed. (I've seen it listed several times as an exa= mple of a critical task, but no other examples come to mind that aren't rec= overable via a new Instruction from the Controller.) So let us define commu= nication with a Controller as always being exempt from suppression. The MA = is configured with the Controller's address so it is possible to mark any T= ask communicating with that address as "never suppress." This marking can b= e done at configuration time (internally by the MA, no Instruction field re= quired) so addresses don't need to be compared at run time. Ken From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Tuesday, June 10, 2014 4:27 AM To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN KO; lmap@ietf= .org Subject: RE: [lmap] Suppression in framework The last bit is important - when we just send a basic suppress message (i.e= . default suppress everything) then this DOESN'T over-ride the flags. I wou= ldn't be in favour of reversing this when selected tasks/schedules are list= ed. I think this would create confusion. Also I'm in favour of not over-riding to give a bit more accidental protect= ion to critical tasks, such as communicating with the Controller. Remember = if we do want to over-ride any flags, the controller is free to either chan= ge those flags or remove the task from the schedules. So we always have the= ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KE= N.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 -- 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB7775706ABexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems that we are e= xpressing two different interpretations of this flag, and we need to conver= ge on one.

 

Definition “A= 221;

What I proposed is a f= lag that *defines* the default suppression behavior of a task, e.g. = in response to a basic suppress message. In that context, Trevor’s fi= rst sentence has no meaning because the flags themselves define the response to a basic suppress message – that is= , there is nothing to override. The MA interprets the basic suppression mes= sage as “do what the flag says” for each Task. If the flag is c= leared, the task is suppressed by default (using Phil’s do-not-suppress polarity – I would reverse it, but that’s a mi= nor point). If the flag is set, the task is not suppressed by default.=

 

Definition “B= 221;

Trevor and Phil, I thi= nk (please correct me if this is wrong) you are interpreting these flags as= identifying exceptions to predefined default suppression behavior. That is= , if the flag is not set the suppression behavior conforms to a fixed definition, but if the flag is set the Task i= s not suppressed. This is a one-way flag – there is no way to use it = to change the default behavior of a Task that is not normally suppressed. I= s this understanding of your interpretation correct?

 

For what it is worth, = I favor “A”. I proposed it to resolve any ambiguity in the defi= nition of Active vs. Passive as it applies to default suppression behavior = while allowing each operator to define that behavior on their own terms. “B” doesn’t achieve either of those = goals.

 

Having said all that, = I agree with you that communication with the Controller should never be sup= pressed. (I’ve seen it listed several times as an example of a critic= al task, but no other examples come to mind that aren’t recoverable via a new Instruction from the Controller.) = So let us define communication with a Controller as always being exempt fro= m suppression. The MA is configured with the Controller’s address so = it is possible to mark any Task communicating with that address as “never suppress.” This marking can be don= e at configuration time (internally by the MA, no Instruction field require= d) so addresses don’t need to be compared at run time.

 

Ken<= /p>

 

From: trevor.burbridge@bt.co= m [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, June 10, 2014 4:27 AM
To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN KO; lm= ap@ietf.org
Subject: RE: [lmap] Suppression in framework

 

The last bit is important – when we just send a b= asic suppress message (i.e. default suppress everything) then this DOESN= 217;T over-ride the flags. I wouldn’t be in favour of reversing this when selected tasks/schedules are listed. I think this woul= d create confusion.

 

Also I’m in favour of not over-riding to give a b= it more accidental protection to critical tasks, such as communicating with= the Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove t= he task from the schedules. So we always have the ability to switch off any= task.

 

Trevor.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 10 June 2014 09:21
To: charles.cook2@c= enturylink.com; KEN.KO@adtran.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My take is that the do-not-suppress flag should not be defined = in the Measurement Method. The controller should be able to set it. for some operators of measurement systems a particular method may = be critical, for some it may be highly optional.

 

Allowing the optional msg to over-ride the do-not-suppress flag= – I don’t think this is very clean. There are some tasks (comm= unication with controller) that would need to be marked as ‘really do not supp= ress, even if the optional msg says so’. Perhaps also it would mean t= hat the normal suppress and optional suppress msgs would have to be process= ed differently.

 

 

 

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

As soon as I hit send, that thought occurred to me as = well, and whether it would be out of scope. 

Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller.  The Network o= wner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Meth= od.

I think I am convinced that maybe this is better handled by an agreement be= tween parties.

Charles

On 6= /9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do th= e right thing, then there seems to be little value in a flag in the Measure= ment Method that prohibits doing the wrong thing.

 

Perhaps if that is the case, this is better handled by = an agreement between parties that would be out of scope for lmap?

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Good point.  Or the Controller can do the configu= ration manipulation in the creation of the Measurement Task (my preference)= so the MA does not have to.  - keep the MA as simple as possible at t= he expense of the Controller.

Charles

On = 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see = some utility in that, but it does complicate the MA which would have to tes= t suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On = 6/9/2014 12:19 PM, KEN KO wrote:

Charles,=

 

Is there a reason to prevent the do-not-suppress flag = from redefining the default suppression behavior suggested for a particular= Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like t= hat would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Regarding suppression (not communication with the Cont= roller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On = 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the opt= ion fields already override default behavior.

 

Given the more general nature of Tasks as you point ou= t, there may be specific tasks which should simply never be suppressed, eit= her by default configuration or optional field. I’m thinking primarily about communication with the Controlle= r. If we protect that, then suppression of anything else should be recovera= ble. And if that is true, I’m still in favor of the optional fields o= verriding the default.

 

Your thoughts?<= /span>

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

&nb= sp;

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppres= s fields would override the default behavior flag. That is, if the do-not-s= uppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule cont= aining the Task), the task would then be suppressed and no error would be t= hrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework=

&nb= sp;

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.<= /p>

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement = Tasks to suppress; the others are not

      suppressed.=   For example, this could be useful if a particular

      Measurement= Task is overloading a Measurement Peer.

 

   o  a set of Measurement = Schedules to suppress; the others are not<= /o:p>

      suppressed.=   For example, suppose the measurement system has

      defined two= Schedules, one with the most critical Measurement

      Tasks and t= he other with less critical ones that create a lot of

      Active Meas= urement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at whic= h suppression begins

 

   o  an end time, at which= suppression ends

 

   o  a demand that the MA = ends its on-going Active Measurement Task(s)

      (and delete= s the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.=

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil





_____________________=
__________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lma=
p




-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com



-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- <=
/pre>

 


Charles Cook 


Principal Architect


Network


5325 Zuni Street; Suit=
e 224


Denver, CO  80221=



Tel:  303.992.895=
2  Fax:  925.281.0662


charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB7775706ABexmb1corpadtran_-- From nobody Tue Jun 10 06:05: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 B67A01B279D for ; Tue, 10 Jun 2014 06:05:15 -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 VLcflj959022 for ; Tue, 10 Jun 2014 06:05:14 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E32D1A0641 for ; Tue, 10 Jun 2014 06:04:55 -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 s5AD4khJ018967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 07:04:46 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2BFAD1E00BB; Tue, 10 Jun 2014 07:04:41 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 897301E006E; Tue, 10 Jun 2014 07:04:40 -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 s5AD1OVe017833; Tue, 10 Jun 2014 08:01:24 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet [151.117.206.27]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s5AD1NOC017799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 08:01:24 -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, 10 Jun 2014 08:01:23 -0500 From: "Bugenhagen, Michael K" To: "Cook, Charles" , "MORTON, ALFRED C (AL)" , KEN KO , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/wgABnHbD//6KwgP//akDg Date: Tue, 10 Jun 2014 13:01:22 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> <53963D1D.4030208@centurylink.com> In-Reply-To: <53963D1D.4030208@centurylink.com> 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/IfdhRnGE3XBwxbtz9FOOkSIB58U Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 13:05:15 -0000 I agree as well. In between this we have the "MA behavior to environment" as well that w= on't be covered by the IPPM test registry. I think that needs to be discussed in the next f2f meeting on both sides of= the fence. I haven't seen anyone propose how to close that issue in a "standard protoc= ol" method or approach, or a testing standard state approach beyond "watch = for cross traffic" wording. -M -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Cook, Charles Sent: Monday, June 09, 2014 6:03 PM To: MORTON, ALFRED C (AL); KEN KO; philip.eardley@bt.com; STARK, BARBARA H;= lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks I agree.=20 My comment was only addressing the details of making measurements. Charles On 6/9/2014 3:34 PM, MORTON, ALFRED C (AL) wrote: > Charles, > > When you say, > "...the Measurement Method defines all possible roles." > it may be true for the details of making measurements. > But I think there are other roles which are equally important to=20 > establish - measurement control protocol roles and test session=20 > protocol roles. > > One of the example figures in the Framework covers OWAMP: > > +----------------+ OWAMP +----------------+ ^ > | OWAMP |<--control--->| MP: | | > | control-client |>test-traffic>| OWAMP server & | IPPM > | fetch-client & |<----fetch----| session-rec'ver| Scope > | session-sender | | | | > | | +----------------+ | > ...|................|....................................v... > | LMAP interface | ^ > +----------------+ | > > The protocol roles, such as control-client <---> server, need to be=20 > specified and communicated from the LMAP MA to the control-client=20 > interface, the device on the left above is not a session-sender by=20 > default, for example. > > In the Measurement Methods written by IPPM, there will typically be=20 > the roles of Source and Destination, and these are the only set of=20 > roles that would normally appear. > This is the material that will appear in the Registry for Performance=20 > metrics - but there won't be any discussion of OWAMP-specifics, just=20 > packet measurement processes. > > So, both Protocol roles and Measurement roles are needed, and only=20 > one can be found in the registry. > > regards, > Al > >> -----Original Message----- >> From: KEN KO [mailto:KEN.KO@adtran.com] >> Sent: Monday, June 09, 2014 2:12 PM >> To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON,=20 >> ALFRED C (AL); STARK, BARBARA H; lmap@ietf.org >> Subject: RE: [lmap] Measurement Methods and Tasks >> >> Yes, that is how I interpret it. >> >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: Monday, June 09, 2014 1:50 PM >> To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com;=20 >> lmap@ietf.org >> Subject: Re: [lmap] Measurement Methods and Tasks >> >> If I understand correctly, the Measurement Method defines all the=20 >> possible roles. The Measurement Task generated by the Control sets=20 >> an Input parameter that selects the role the MA is to perform. >> >> Charles >> >> On 6/9/2014 10:56 AM, KEN KO wrote: >>>> ... it's probably more consistent with ippm for it to be a registry=20 >>>> of Methods. So then the ***Measurement Task Configuration*** needs=20 >>>> an Input Parameter (or some other kind of configuration option) to=20 >>>> choose between different roles (client, server...) >>> With that one (hopefully minor) tweak, +1 >>> >> -- >> >> 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 --=20 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 From nobody Tue Jun 10 06:06:53 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 63D2D1B27A4 for ; Tue, 10 Jun 2014 06:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.24 X-Spam-Level: X-Spam-Status: No, score=-4.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro0UTZbOMYGJ for ; Tue, 10 Jun 2014 06:06:43 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34A91B2799 for ; Tue, 10 Jun 2014 06:06:42 -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 2e207935.2ba828606940.622871.00-2494.1582452.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 10 Jun 2014 13:06:42 +0000 (UTC) X-MXL-Hash: 539702e202da21df-08dd71a7dee835e9192b3f6efad08293fa699316 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 ed207935.0.622825.00-2340.1582340.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 10 Jun 2014 13:06:40 +0000 (UTC) X-MXL-Hash: 539702e06be952c9-10d9cd7779cc46c95a838a4950a09e32405386c7 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 s5AD6cXC012251; Tue, 10 Jun 2014 09:06:38 -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 s5AD6V2l012144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 09:06:35 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 10 Jun 2014 13:06:18 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 09:06:18 -0400 From: "STARK, BARBARA H" To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "KEN.KO@adtran.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAKisaAAACuMgAAAfCogAAAu5sAAAFs7YD//8R4i4ABBfmAgAABkID///8C8A== Date: Tue, 10 Jun 2014 13:06:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE7E58@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.103.76] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE7E58GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=eY56GQPitMMA:10 a=ofMgfj31e3cA:10 a=4CCq8TzuqIwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8 a=eJNrpioGAAAA:8 a] X-AnalysisOut: [=RGsiGTvY4sKeA8Dj9SgA:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:1] X-AnalysisOut: [0 a=pjBFNBMRyLAA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=] X-AnalysisOut: [Pwbduc0PQ3sA:10 a=DvnSUQUdWHYA:10 a=6wTGN070d7sh571l:21 a=] X-AnalysisOut: [mnEN7R8a7qSafn8h:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=go] X-AnalysisOut: [1B5g1xr3_PA32A7J0A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a] X-AnalysisOut: [=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=v6HAOw2PcvmmamuM:21 a] X-AnalysisOut: [=vDDSXxoiP0HsZiKU:21 a=jH5AdF2V8MsLFf8l:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/1-0-Rwsi5qbbvZHT4XoqaTmL34s Subject: Re: [lmap] Suppression in 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: Tue, 10 Jun 2014 13:06:50 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DE7E58GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree. This flag we are talking about could mean one of 2 things (providing the tr= ue and false of each): 1. Do not ever suppress / suppress in absence of specific list 2. Default suppress behavior (in the absence of a specific list) I hear Phil and Trevor in favor of 1. I'm in favor of 2. 2 is definitely no= t confusing -- I see this sort of override behavior all the time. In fact, = it's easier to code than the first, because once you have a specific list y= ou don't have to compare it against the flag to see if it's allowed. Also, = if certain tasks don't get suppressed (contrary to the specific list I just= sent) there would need to be specific error messages and/or logs explainin= g why the MA ignored my specific instructions, and I would have to go look = at these messages to figure out why my suppress message partially failed, c= raft a message to update the flags, and then re-suppress. Or, do I? If I do= change the flag after having issued a suppress message, will the task be s= uppressed because of the prior suppress message that is in effect, or do I = have to resend suppress? I don't know. Option 1 is creating confusion for m= e. Since the same entity controls the flag as controls the suppress message, I= don't see the need for this added level of protection (flag cannot be over= ridden). Don't shoot yourself in the foot. It's a bad idea. But it's not my= job to keep someone from picking up a weapon and pointing it at their foot= . I'm not a babysitter. Personally, I would design the MA-Controller interface with code that would= never allow it to be suppressed. I don't particularly think this needs to = be mentioned in the info model or framework, because it's a pretty obvious = design choice. But I also don't care if it does get mentioned. I just find = that documents get incredibly long when all obvious design choices get writ= ten down. Another possible design choice would be that the Controller system that let= s the suppress message be created or issued by a human being compares the i= tems in the specific list against the flags up front and warns the human be= ing with an "Are you sure, because you'll be overriding these flags?" messa= ge. Or if no specific list is provided the system presents the human being = with a "These are the tasks that will be suppressed; are you sure you want = to do this?" message. There are plenty of ways to do this without making th= e flag an absolute that can easily be overwritten (but not overridden). Barbara IMO, the simple and not confusing behavior is 2. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Tuesday, June 10, 2014 4:27 AM To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN.KO@adtran.com= ; lmap@ietf.org Subject: Re: [lmap] Suppression in framework The last bit is important - when we just send a basic suppress message (i.e= . default suppress everything) then this DOESN'T over-ride the flags. I wou= ldn't be in favour of reversing this when selected tasks/schedules are list= ed. I think this would create confusion. Also I'm in favour of not over-riding to give a bit more accidental protect= ion to critical tasks, such as communicating with the Controller. Remember = if we do want to over-ride any flags, the controller is free to either chan= ge those flags or remove the task from the schedules. So we always have the= ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KEN.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 -- 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 --_000_2D09D61DDFA73D4C884805CC7865E61130DE7E58GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I disagree.=

This flag we are talki= ng about could mean one of 2 things (providing the true and false of each):=

1.&n= bsp;      Do not ever su= ppress / suppress in absence of specific list

2.&n= bsp;      Default suppre= ss behavior (in the absence of a specific list)

 

I hear Phil and Trevor= in favor of 1. I’m in favor of 2. 2 is definitely not confusing -- I= see this sort of override behavior all the time. In fact, it’s easie= r to code than the first, because once you have a specific list you don’t have to compare it against the flag to see= if it’s allowed. Also, if certain tasks don’t get suppressed (= contrary to the specific list I just sent) there would need to be specific = error messages and/or logs explaining why the MA ignored my specific instructions, and I would have to go look at these messages to= figure out why my suppress message partially failed, craft a message to up= date the flags, and then re-suppress. Or, do I? If I do change the flag aft= er having issued a suppress message, will the task be suppressed because of the prior suppress message that is = in effect, or do I have to resend suppress? I don’t know. Option 1 is= creating confusion for me.

 

Since the same entity = controls the flag as controls the suppress message, I don’t see the n= eed for this added level of protection (flag cannot be overridden). DonR= 17;t shoot yourself in the foot. It’s a bad idea. But it’s not my job to keep someone from picking up a weapon and poi= nting it at their foot. I’m not a babysitter.

 

Personally, I would de= sign the MA-Controller interface with code that would never allow it to be = suppressed. I don’t particularly think this needs to be mentioned in = the info model or framework, because it’s a pretty obvious design choice. But I also don’t care if it does get= mentioned. I just find that documents get incredibly long when all obvious= design choices get written down.

 

Another possible desig= n choice would be that the Controller system that lets the suppress message= be created or issued by a human being compares the items in the specific l= ist against the flags up front and warns the human being with an “Are you sure, because you’ll be overr= iding these flags?” message. Or if no specific list is provided the s= ystem presents the human being with a “These are the tasks that will = be suppressed; are you sure you want to do this?” message. There are plenty of ways to do this without making the flag an absolute th= at can easily be overwritten (but not overridden).

Barbara

 

IMO, the simple and no= t confusing behavior is 2.

Barbara

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.com
Sent: Tuesday, June 10, 2014 4:27 AM
To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN.KO@adt= ran.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

The las= t bit is important – when we just send a basic suppress message (i.e.= default suppress everything) then this DOESN’T over-ride the flags. = I wouldn’t be in favour of reversing this when selected tasks/schedules are listed. I think this would create confusion.

&n= bsp;

Also I&= #8217;m in favour of not over-riding to give a bit more accidental protecti= on to critical tasks, such as communicating with the Controller. Remember i= f we do want to over-ride any flags, the controller is free to either change those flags or remove the task from the schedules= . So we always have the ability to switch off any task.

&n= bsp;

Trevor.=

&n= bsp;

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 10 June 2014 09:21
To: charles.cook2@centurylink.com; KEN.KO@adtran.com; lmap@ietf.org<= br> Subject: Re: [lmap] Suppression in framework

 

My take is that= the do-not-suppress flag should not be defined in the Measurement Method. = The controller should be able to set it. for some operators of measurement systems a particular method may be critical, for some it ma= y be highly optional.

 

Allowing the op= tional msg to over-ride the do-not-suppress flag – I don’t thin= k this is very clean. There are some tasks (communication with controller) that would need to be marked as ‘really do not suppress, even if the= optional msg says so’. Perhaps also it would mean that the normal su= ppress and optional suppress msgs would have to be processed differently.

 

 

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

= As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. 

Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller.  The Network o= wner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Meth= od.

I think I am convinced that maybe this is better handled by an agreement be= tween parties.

Charles

On 6/9/2014 2:27 PM, KEN KO wro= te:

But if = a third party Controller can be trusted to do the right thing, then there s= eems to be little value in a flag in the Measurement Method that prohibits = doing the wrong thing.

 <= /span>

Perhaps= if that is the case, this is better handled by an agreement between partie= s that would be out of scope for lmap?

 <= /span>

From: Charles Cook [mailto:charles.cook= 2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nbs= p;

Good point.  Or the Controller can do the configu= ration manipulation in the creation of the Measurement Task (my preference)= so the MA does not have to.  - keep the MA as simple as possible at t= he expense of the Controller.

Charles

On 6= /9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see s= ome utility in that, but it does complicate the MA which would have to test= suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On = 6/9/2014 12:19 PM, KEN KO wrote:

Charles,=

 

Is there a reason to prevent the do-not-suppress flag = from redefining the default suppression behavior suggested for a particular= Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like t= hat would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Regarding suppression (not communication with the Cont= roller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On = 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the opt= ion fields already override default behavior.

 

Given the more general nature of Tasks as you point ou= t, there may be specific tasks which should simply never be suppressed, eit= her by default configuration or optional field. I’m thinking primarily about communication with the Controlle= r. If we protect that, then suppression of anything else should be recovera= ble. And if that is true, I’m still in favor of the optional fields o= verriding the default.

 

Your thoughts?<= /span>

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

&nb= sp;

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppres= s fields would override the default behavior flag. That is, if the do-not-s= uppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule cont= aining the Task), the task would then be suppressed and no error would be t= hrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework=

&nb= sp;

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.<= /p>

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement Tasks to suppress= ; the others are not

      suppressed.  For exampl= e, this could be useful if a particular

      Measurement Task is overload= ing a Measurement Peer.

 

   o  a set of Measurement Schedules to supp= ress; the others are not

      suppressed.  For exampl= e, suppose the measurement system has

      defined two Schedules, one w= ith the most critical Measurement

      Tasks and the other with les= s critical ones that create a lot of=

      Active Measurement Traffic, = then it may only want to suppress the

      second.

 

   o  a start time, at which suppression beg= ins

 

   o  an end time, at which suppression ends=

 

   o  a demand that the MA ends its on-going= Active Measurement Task(s)

      (and deletes the associated = partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.=

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil





_____________________=
__________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lma=
p




-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com



-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- <=
/pre>

 


Charles Cook 


Principal Architect


Network


5325 Zuni Street; Suit=
e 224


Denver, CO  80221=



Tel:  303.992.895=
2  Fax:  925.281.0662


charles.cook2@centurylink.com

 

-- 
 
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
--_000_2D09D61DDFA73D4C884805CC7865E61130DE7E58GAALPA1MSGUSRBF_-- From nobody Tue Jun 10 06:15: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 158DF1A00B0 for ; Tue, 10 Jun 2014 06:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 jM-8oc2IFZuF for ; Tue, 10 Jun 2014 06:15:29 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2631A0087 for ; Tue, 10 Jun 2014 06:15:29 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO p01c12o143.mxlogic.net) by p01c12o143.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 1f407935.2b0e4422c940.96582.00-579.251013.p01c12o143.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:15:29 -0600 (MDT) X-MXL-Hash: 539704f15332005b-d060d67a616f450144111cd7b14753462d08c54b Received: from unknown [76.164.174.82] by p01c12o143.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id db407935.0.96063.00-207.249713.p01c12o143.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:14:38 -0600 (MDT) X-MXL-Hash: 539704be37207213-6164c49898d366ebc56bb99934658ecd8a5b32d6 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 08:14:33 -0500 From: KEN KO To: "Bugenhagen, Michael K" , "Cook, Charles" , "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/wgABnHbD//6KwgP//akDg//7RUAA= Date: Tue, 10 Jun 2014 13:14:32 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> <53963D1D.4030208@centurylink.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=XcAHzeJ5 c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=J_N6KFswAAAA:8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=zQ] X-AnalysisOut: [P7CpKOAAAA:8 a=VOIG6KdTNqQa9oZKYswA:9 a=uUt2OjUPJ7N_mwLD:2] X-AnalysisOut: [1 a=3n-hPYf4HMtptnZm:21 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:1] X-AnalysisOut: [0 a=pjBFNBMRyLAA:10 a=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a=Hz7IrDYlS0cA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061008); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/nKjKXnrpF-bWNdEADOmg465lPbE Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 13:15:37 -0000 Mike, You bring up an interesting point.=20 One approach would be to include environmental options in the formal defini= tion of the Measurement Method. Another approach would be to define a set of environmental options independ= ent of Measurement Method (another registry???) that can be set as optional= input parameters in any Measurement Task Configuration. I hadn't thought about this before, but it seems to me that the second appr= oach has merit. Comments? Ken -----Original Message----- From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com]=20 Sent: Tuesday, June 10, 2014 9:01 AM To: Cook, Charles; MORTON, ALFRED C (AL); KEN KO; philip.eardley@bt.com; ST= ARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] Measurement Methods and Tasks I agree as well. In between this we have the "MA behavior to environment" as well that w= on't be covered by the IPPM test registry. I think that needs to be discussed in the next f2f meeting on both sides of= the fence. I haven't seen anyone propose how to close that issue in a "standard protoc= ol" method or approach, or a testing standard state approach beyond "watch = for cross traffic" wording. -M -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Cook, Charles Sent: Monday, June 09, 2014 6:03 PM To: MORTON, ALFRED C (AL); KEN KO; philip.eardley@bt.com; STARK, BARBARA H;= lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks I agree.=20 My comment was only addressing the details of making measurements. Charles On 6/9/2014 3:34 PM, MORTON, ALFRED C (AL) wrote: > Charles, > > When you say, > "...the Measurement Method defines all possible roles." > it may be true for the details of making measurements. > But I think there are other roles which are equally important to=20 > establish - measurement control protocol roles and test session=20 > protocol roles. > > One of the example figures in the Framework covers OWAMP: > > +----------------+ OWAMP +----------------+ ^ > | OWAMP |<--control--->| MP: | | > | control-client |>test-traffic>| OWAMP server & | IPPM > | fetch-client & |<----fetch----| session-rec'ver| Scope > | session-sender | | | | > | | +----------------+ | > ...|................|....................................v... > | LMAP interface | ^ > +----------------+ | > > The protocol roles, such as control-client <---> server, need to be=20 > specified and communicated from the LMAP MA to the control-client=20 > interface, the device on the left above is not a session-sender by=20 > default, for example. > > In the Measurement Methods written by IPPM, there will typically be=20 > the roles of Source and Destination, and these are the only set of=20 > roles that would normally appear. > This is the material that will appear in the Registry for Performance=20 > metrics - but there won't be any discussion of OWAMP-specifics, just=20 > packet measurement processes. > > So, both Protocol roles and Measurement roles are needed, and only=20 > one can be found in the registry. > > regards, > Al > >> -----Original Message----- >> From: KEN KO [mailto:KEN.KO@adtran.com] >> Sent: Monday, June 09, 2014 2:12 PM >> To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON,=20 >> ALFRED C (AL); STARK, BARBARA H; lmap@ietf.org >> Subject: RE: [lmap] Measurement Methods and Tasks >> >> Yes, that is how I interpret it. >> >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: Monday, June 09, 2014 1:50 PM >> To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com;=20 >> lmap@ietf.org >> Subject: Re: [lmap] Measurement Methods and Tasks >> >> If I understand correctly, the Measurement Method defines all the=20 >> possible roles. The Measurement Task generated by the Control sets=20 >> an Input parameter that selects the role the MA is to perform. >> >> Charles >> >> On 6/9/2014 10:56 AM, KEN KO wrote: >>>> ... it's probably more consistent with ippm for it to be a registry=20 >>>> of Methods. So then the ***Measurement Task Configuration*** needs=20 >>>> an Input Parameter (or some other kind of configuration option) to=20 >>>> choose between different roles (client, server...) >>> With that one (hopefully minor) tweak, +1 >>> >> -- >> >> 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 --=20 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 From nobody Tue Jun 10 06:18:32 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 57BC71A0071 for ; Tue, 10 Jun 2014 06:18:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...D9D9BA4B2@EMV64-UKRD.domain1.systemhost.net>\n X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDUYJiArcLW9 for ; Tue, 10 Jun 2014 06:18:23 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AF31A00A8 for ; Tue, 10 Jun 2014 06:18:23 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO p01c11o142.mxlogic.net) by p01c11o142.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id f9507935.2b6665e02940.112236.00-598.282331.p01c11o142.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:18:23 -0600 (MDT) X-MXL-Hash: 5397059f140e4b34-ce4b600e4b714e8ed6f1c37a251f31809d2a9b50 Received: from unknown [76.164.174.81] by p01c11o142.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id 78507935.0.111212.00-214.281703.p01c11o142.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:18:01 -0600 (MDT) X-MXL-Hash: 53970589162f2792-71a1f3e459785e94d55d364e3651231494634ff2 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 08:17:11 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hA= Date: Tue, 10 Jun 2014 13:17:11 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77757076Bexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=ecazft0H c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=e9qsufxtAAAA:] X-AnalysisOut: [8 a=J_N6KFswAAAA:8 a=48vgC7mUAAAA:8 a=Y7DWF4qTjZpIv50UAqIA] X-AnalysisOut: [:9 a=I5I_Or5qbGmwgoQ8:21 a=adNSbYX3FztccbA4:21 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a=W1qU_X6G3J8A:] X-AnalysisOut: [10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a] X-AnalysisOut: [=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=taVhYXxY71tfmyl7:21 a=1] X-AnalysisOut: [r1WwWZa21ETF-2s:21 a=P6JUG7OUlrw92kQw:21 a=gKO2Hq4RSVkA:10] X-AnalysisOut: [ a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061008); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ahUbU0qYuAmgRUSE-RKphXEMetA Subject: Re: [lmap] Suppression in 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: Tue, 10 Jun 2014 13:18:29 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757076Bexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry if this is a duplicate - I had to reset my membership in the lmap lis= t. It seems that we are expressing two different interpretations of this flag,= and we need to converge on one. Definition "A" What I proposed is a flag that *defines* the default suppression behavior o= f a task, e.g. in response to a basic suppress message. In that context, Tr= evor's first sentence has no meaning because the flags themselves define th= e response to a basic suppress message - that is, there is nothing to overr= ide. The MA interprets the basic suppression message as "do what the flag s= ays" for each Task. If the flag is cleared, the task is suppressed by defau= lt (using Phil's do-not-suppress polarity - I would reverse it, but that's = a minor point). If the flag is set, the task is not suppressed by default. Definition "B" Trevor and Phil, I think (please correct me if this is wrong) you are inter= preting these flags as identifying exceptions to predefined default suppres= sion behavior. That is, if the flag is not set the suppression behavior con= forms to a fixed definition, but if the flag is set the Task is not suppres= sed. This is a one-way flag - there is no way to use it to change the defau= lt behavior of a Task that is not normally suppressed. Is this understandin= g of your interpretation correct? For what it is worth, I favor "A". I proposed it to resolve any ambiguity i= n the definition of Active vs. Passive as it applies to default suppression= behavior while allowing each operator to define that behavior on their own= terms. "B" doesn't achieve either of those goals. Having said all that, I agree with you that communication with the Controll= er should never be suppressed. (I've seen it listed several times as an exa= mple of a critical task, but no other examples come to mind that aren't rec= overable via a new Instruction from the Controller.) So let us define commu= nication with a Controller as always being exempt from suppression. The MA = is configured with the Controller's address so it is possible to mark any T= ask communicating with that address as "never suppress." This marking can b= e done at configuration time (internally by the MA, no Instruction field re= quired) so addresses don't need to be compared at run time. Ken From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Tuesday, June 10, 2014 4:27 AM To: philip.eardley@bt.com; charles.cook2@cent= urylink.com; KEN KO; lmap@ietf.org Subject: RE: [lmap] Suppression in framework The last bit is important - when we just send a basic suppress message (i.e= . default suppress everything) then this DOESN'T over-ride the flags. I wou= ldn't be in favour of reversing this when selected tasks/schedules are list= ed. I think this would create confusion. Also I'm in favour of not over-riding to give a bit more accidental protect= ion to critical tasks, such as communicating with the Controller. Remember = if we do want to over-ride any flags, the controller is free to either chan= ge those flags or remove the task from the schedules. So we always have the= ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KE= N.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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 -- 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 -- 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 -- 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757076Bexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry if this is a dup= licate – I had to reset my membership in the lmap list.

 

It seems that we are e= xpressing two different interpretations of this flag, and we need to conver= ge on one.

 

Definition “A= 221;

What I proposed is a f= lag that *defines* the default suppression behavior of a task, e.g. = in response to a basic suppress message. In that context, Trevor’s fi= rst sentence has no meaning because the flags themselves define the response to a basic suppress message – that is= , there is nothing to override. The MA interprets the basic suppression mes= sage as “do what the flag says” for each Task. If the flag is c= leared, the task is suppressed by default (using Phil’s do-not-suppress polarity – I would reverse it, but that’s a mi= nor point). If the flag is set, the task is not suppressed by default.=

 

Definition “B= 221;

Trevor and Phil, I thi= nk (please correct me if this is wrong) you are interpreting these flags as= identifying exceptions to predefined default suppression behavior. That is= , if the flag is not set the suppression behavior conforms to a fixed definition, but if the flag is set the Task i= s not suppressed. This is a one-way flag – there is no way to use it = to change the default behavior of a Task that is not normally suppressed. I= s this understanding of your interpretation correct?

 

For what it is worth, = I favor “A”. I proposed it to resolve any ambiguity in the defi= nition of Active vs. Passive as it applies to default suppression behavior = while allowing each operator to define that behavior on their own terms. “B” doesn’t achieve either of those = goals.

 

Having said all that, = I agree with you that communication with the Controller should never be sup= pressed. (I’ve seen it listed several times as an example of a critic= al task, but no other examples come to mind that aren’t recoverable via a new Instruction from the Controller.) = So let us define communication with a Controller as always being exempt fro= m suppression. The MA is configured with the Controller’s address so = it is possible to mark any Task communicating with that address as “never suppress.” This marking can be don= e at configuration time (internally by the MA, no Instruction field require= d) so addresses don’t need to be compared at run time.

 

Ken<= /p>

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, June 10, 2014 4:27 AM
To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN KO; lmap@ietf.org
Subject: RE: [lmap] Suppression in framework

 

The last bit is important – when we just send a = basic suppress message (i.e. default suppress everything) then this DOESN&#= 8217;T over-ride the flags. I wouldn’t be in favour of reversing this when selected tasks/schedules are listed. I think this w= ould create confusion.

 

Also I’m in favour of not over-riding to give a = bit more accidental protection to critical tasks, such as communicating wit= h the Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove t= he task from the schedules. So we always have the ability to switch off any= task.

 

Trevor.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 10 June 2014 09:21
To: charles.cook2@c= enturylink.com; KEN.KO@adtran.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My take is that the do-not-suppress flag should not be defined= in the Measurement Method. The controller should be able to set it. for some operators of measurement systems a particular method may = be critical, for some it may be highly optional.

 

Allowing the optional msg to over-ride the do-not-suppress fla= g – I don’t think this is very clean. There are some tasks (com= munication with controller) that would need to be marked as ‘really do not supp= ress, even if the optional msg says so’. Perhaps also it would mean t= hat the normal suppress and optional suppress msgs would have to be process= ed differently.

 

 

 

From: Charles Cook [mailto:charles.cook2@centurylink.= com]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

As soon as I hit send, that thought occurred to me as = well, and whether it would be out of scope. 

Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller.  The Network o= wner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Meth= od.

I think I am convinced that maybe this is better handled by an agreement be= tween parties.

Charles

On = 6/9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do t= he right thing, then there seems to be little value in a flag in the Measur= ement Method that prohibits doing the wrong thing.

 

Perhaps if that is the case, this is better handled by= an agreement between parties that would be out of scope for lmap?

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Good point.  Or the Controller can do the configu= ration manipulation in the creation of the Measurement Task (my preference)= so the MA does not have to.  - keep the MA as simple as possible at t= he expense of the Controller.

Charles

On = 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see = some utility in that, but it does complicate the MA which would have to tes= t suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On = 6/9/2014 12:19 PM, KEN KO wrote:

Charles,=

 

Is there a reason to prevent the do-not-suppress flag = from redefining the default suppression behavior suggested for a particular= Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like t= hat would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

&nb= sp;

Regarding suppression (not communication with the Cont= roller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On = 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the opt= ion fields already override default behavior.

 

Given the more general nature of Tasks as you point ou= t, there may be specific tasks which should simply never be suppressed, eit= her by default configuration or optional field. I’m thinking primarily about communication with the Controlle= r. If we protect that, then suppression of anything else should be recovera= ble. And if that is true, I’m still in favor of the optional fields o= verriding the default.

 

Your thoughts?<= /span>

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

&nb= sp;

Over-ride might make it a bit too easy to accidentally suppres= s a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not jus= t measurement tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-sup= press flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

&nb= sp;

I would think that information in the optional Suppres= s fields would override the default behavior flag. That is, if the do-not-s= uppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule cont= aining the Task), the task would then be suppressed and no error would be t= hrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework=

&nb= sp;

So we have agreed to modify suppression so the default behaviour is that = tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.<= /p>

Question: what do we want the impact of the flag to be when we have the m= ore complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measurem= ent Task”, my proposal is to basically keep the current text unaltere= d:

            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

<<=
 Optionally the Suppression information m=
ay

   include:

 

   o  a set of Measurement = Tasks to suppress; the others are not

      suppressed.=   For example, this could be useful if a particular

      Measurement= Task is overloading a Measurement Peer.

 

   o  a set of Measurement = Schedules to suppress; the others are not<= /o:p>

      suppressed.=   For example, suppose the measurement system has

      defined two= Schedules, one with the most critical Measurement

      Tasks and t= he other with less critical ones that create a lot of

      Active Meas= urement Traffic, then it may only want to suppress the

      second.

 

   o  a start time, at whic= h suppression begins

 

   o  an end time, at which= suppression ends

 

   o  a demand that the MA = ends its on-going Active Measurement Task(s)

      (and delete= s the associated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” t= hen the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller sa= ys “Suppress Schedule #49”, then the MA checks the do-not-suppr= ess flag for Tasks in this schedule and either throws an error or doesnR= 17;t start any new Tasks in this schedule.=

 

I’ll tweak the text to say this (as well as removing the refs to Ac= tive).

I’ll also make clear that the Controller sets the do-not-suppress f= lag for a Task (it isn’t something that the MA decides about).=

 

Thanks

phil




_____________________=
__________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lma=
p



-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- =

 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.89=
52  Fax:  925.281.0662
charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB77757076Bexmb1corpadtran_-- From nobody Tue Jun 10 06:19:53 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 71BDD1A0087 for ; Tue, 10 Jun 2014 06:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 HagboDQmG03q for ; Tue, 10 Jun 2014 06:19:45 -0700 (PDT) Received: from p02c11o149.mxlogic.net (p02c11o149.mxlogic.net [208.65.144.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EBB1A00A8 for ; Tue, 10 Jun 2014 06:19:45 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO p02c11o149.mxlogic.net) by p02c11o149.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 1f507935.2adf7760b940.37110.00-530.100957.p02c11o149.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:19:45 -0600 (MDT) X-MXL-Hash: 539705f17eb82adb-d260144657ef538168bbfdf0f688f42c174b178d Received: from unknown [76.164.174.81] by p02c11o149.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id bc507935.0.36469.00-358.100123.p02c11o149.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 07:19:08 -0600 (MDT) X-MXL-Hash: 539705cc0443adb2-6af4393f64988c04674a3cbc0f5cc0c2efb56ca5 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 08:18:21 -0500 From: KEN KO To: "Bugenhagen, Michael K" , "Cook, Charles" , "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Thread-Topic: [lmap] Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwAMxqEAAAUej4AAKwUAAABqyt0AAApfC2D//72fgIAATZ/wgABnHbD//6KwgP//akDg//7RUAD//aBvcA== Date: Tue, 10 Jun 2014 13:18:21 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <5391D622.8060307@centurylink.com>, <2D09D61DDFA73D4C884805CC7865E61130DE6DE3@GAALPA1MSGUSRBF.ITServices.sbc.com> <2845723087023D4CB5114223779FA9C80178E0CDBA@njfpsrvexg8.research.att.com> <5395F3C7.6090005@centurylink.com> <2845723087023D4CB5114223779FA9C80179AD4EE2@njfpsrvexg8.research.att.com> <53963D1D.4030208@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=VY95PTZ9 c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=mUbaKL4_SQQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=J_N6KFswAAAA:8 a=e9qsufxtAAAA:8 a=48vgC7mUAAAA:8 a=zQ] X-AnalysisOut: [P7CpKOAAAA:8 a=wav8NLlvxRs4Lt-Zl58A:9 a=ZMyPPv1ndweyB5n4:2] X-AnalysisOut: [1 a=VIdMFlewJY9j7Jhl:21 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:1] X-AnalysisOut: [0 a=pjBFNBMRyLAA:10 a=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=] X-AnalysisOut: [lZB815dzVvQA:10 a=DvnSUQUdWHYA:10 a=Hz7IrDYlS0cA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061008); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/8E3RkdTDi8kWJOHcxmRN1ni6JJM Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 13:19:51 -0000 Sorry if this is also a duplicate - I had to reset my membership in the lma= p list. Mike, You bring up an interesting point.=20 One approach would be to include environmental options in the formal defini= tion of the Measurement Method. Another approach would be to define a set of environmental options independ= ent of Measurement Method (another registry???) that can be set as optional= input parameters in any Measurement Task Configuration. I hadn't thought about this before, but it seems to me that the second appr= oach has merit. Comments? Ken -----Original Message----- From: Bugenhagen, Michael K [mailto:Michael.K.Bugenhagen@centurylink.com] Sent: Tuesday, June 10, 2014 9:01 AM To: Cook, Charles; MORTON, ALFRED C (AL); KEN KO; philip.eardley@bt.com; ST= ARK, BARBARA H; lmap@ietf.org Subject: RE: [lmap] Measurement Methods and Tasks I agree as well. In between this we have the "MA behavior to environment" as well that w= on't be covered by the IPPM test registry. I think that needs to be discussed in the next f2f meeting on both sides of= the fence. I haven't seen anyone propose how to close that issue in a "standard protoc= ol" method or approach, or a testing standard state approach beyond "watch = for cross traffic" wording. -M -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Cook, Charles Sent: Monday, June 09, 2014 6:03 PM To: MORTON, ALFRED C (AL); KEN KO; philip.eardley@bt.com; STARK, BARBARA H;= lmap@ietf.org Subject: Re: [lmap] Measurement Methods and Tasks I agree.=20 My comment was only addressing the details of making measurements. Charles On 6/9/2014 3:34 PM, MORTON, ALFRED C (AL) wrote: > Charles, > > When you say, > "...the Measurement Method defines all possible roles." > it may be true for the details of making measurements. > But I think there are other roles which are equally important to=20 > establish - measurement control protocol roles and test session=20 > protocol roles. > > One of the example figures in the Framework covers OWAMP: > > +----------------+ OWAMP +----------------+ ^ > | OWAMP |<--control--->| MP: | | > | control-client |>test-traffic>| OWAMP server & | IPPM > | fetch-client & |<----fetch----| session-rec'ver| Scope > | session-sender | | | | > | | +----------------+ | > ...|................|....................................v... > | LMAP interface | ^ > +----------------+ | > > The protocol roles, such as control-client <---> server, need to be=20 > specified and communicated from the LMAP MA to the control-client=20 > interface, the device on the left above is not a session-sender by=20 > default, for example. > > In the Measurement Methods written by IPPM, there will typically be=20 > the roles of Source and Destination, and these are the only set of=20 > roles that would normally appear. > This is the material that will appear in the Registry for Performance=20 > metrics - but there won't be any discussion of OWAMP-specifics, just=20 > packet measurement processes. > > So, both Protocol roles and Measurement roles are needed, and only=20 > one can be found in the registry. > > regards, > Al > >> -----Original Message----- >> From: KEN KO [mailto:KEN.KO@adtran.com] >> Sent: Monday, June 09, 2014 2:12 PM >> To: charles.cook2@centurylink.com; philip.eardley@bt.com; MORTON,=20 >> ALFRED C (AL); STARK, BARBARA H; lmap@ietf.org >> Subject: RE: [lmap] Measurement Methods and Tasks >> >> Yes, that is how I interpret it. >> >> -----Original Message----- >> From: Charles Cook [mailto:charles.cook2@centurylink.com] >> Sent: Monday, June 09, 2014 1:50 PM >> To: KEN KO; philip.eardley@bt.com; acmorton@att.com; bs7652@att.com;=20 >> lmap@ietf.org >> Subject: Re: [lmap] Measurement Methods and Tasks >> >> If I understand correctly, the Measurement Method defines all the=20 >> possible roles. The Measurement Task generated by the Control sets=20 >> an Input parameter that selects the role the MA is to perform. >> >> Charles >> >> On 6/9/2014 10:56 AM, KEN KO wrote: >>>> ... it's probably more consistent with ippm for it to be a registry=20 >>>> of Methods. So then the ***Measurement Task Configuration*** needs=20 >>>> an Input Parameter (or some other kind of configuration option) to=20 >>>> choose between different roles (client, server...) >>> With that one (hopefully minor) tweak, +1 >>> >> -- >> >> 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 --=20 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 From nobody Tue Jun 10 06:41: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 2610A1A010D for ; Tue, 10 Jun 2014 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 ux70YRu13s7x for ; Tue, 10 Jun 2014 06:41:47 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6BC1A011E for ; Tue, 10 Jun 2014 06:41:47 -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 b1b07935.2ba83801f940.647293.00-2401.1635985.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 10 Jun 2014 13:41:47 +0000 (UTC) X-MXL-Hash: 53970b1b6a598dc7-0e860e616e0e78b7ceace189cb1f8518631f3713 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 71b07935.0.647250.00-2370.1635868.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 10 Jun 2014 13:41:45 +0000 (UTC) X-MXL-Hash: 53970b194039d469-c658bfc6dc1d0ee4320b4e63a9502befed8f6a47 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 s5ADfgnn026590; Tue, 10 Jun 2014 09:41:43 -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 s5ADfc1g026562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 09:41:40 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (GAALPA1MSGHUB9F.itservices.sbc.com [130.8.36.92]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 10 Jun 2014 13:41:28 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 09:41:28 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwDHH2JgAADOIUA= Date: Tue, 10 Jun 2014 13:41:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE7EA1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.103.76] 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=Ro1y2laK c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Pb0a8ExErrEA:10 a=ofMgfj31e3cA:10 a=4CCq8TzuqIwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jGZTafl1ceYGWVzEO_kA:9 a=CjuIK1q_8ugA:10 a=RSxdEN] X-AnalysisOut: [CEG5Zt5Oq_:21 a=0zrZ0y68TiN-2ZiJ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/OUDA0-bHSKu84twt-xkYaANDNqU Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 13:41:50 -0000 > Can I suggest a mod: > Measurement Task: The action performed by a particular Measurement > Agent that consists of the single operation of the Measurement Method at = a > particular time and with all its Input Parameters set to specific values. >=20 > Ie if a Method involves two MAs then a particular Task is what one MA doe= s > (and the other MA needs to be instructed with another Task) I find the proposed definition confusing. I'm assuming that you're using Me= asurement Method to identify a holistic technique (because Charles had sugg= ested it could be used to identify a specific role of a holistic technique)= ? A single operation of a holistic technique that has multiple roles would = involve all necessary roles. So, IMO, =20 "the action that consists of the single operation of the Measurement Method= at a particular time" would involve all necessary roles (all MAs participa= ting in this action). It's just not possible for a single MA to perform an action that equates to= a single operation of a multi-MA Measurement Method. I agree with your 2nd sentence, but the proposed definition doesn't say thi= s at all. Is there a reason why the word "role" is being avoided? I see this word use= d in several ippm RFCs.=20 I would prefer: Measurement Task: The action performed by a particular Measurement Agent that consists of the single operation of a Measurement Method role at= a particular time and with all of the role's Input Parameters set to specific= values. Alternately, we could go with Charles' approach and define "Measurement Met= hod" as "the role of a participating point in a holistic measurement techni= que". Then the proposed definition would be accurate. Personally, I think t= his may add to confusion, because so many people already consider "Measurem= ent Method" to be the holistic technique.=20 Barbara From nobody Tue Jun 10 07:51: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 EDC281A01A8 for ; Tue, 10 Jun 2014 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 BC06HNRbrIpY for ; Tue, 10 Jun 2014 07:51:48 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF1B1A0182 for ; Tue, 10 Jun 2014 07:51:48 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 38b17935.0.2948676.00-2022.8226168.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 10 Jun 2014 14:51:48 +0000 (UTC) X-MXL-Hash: 53971b842fc3196c-34130102273e0b0a8d50dcd042fb6c290710a310 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 s5AEpldj018328 for ; Tue, 10 Jun 2014 10:51:47 -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 s5AEpfUG018313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2014 10:51:43 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 10 Jun 2014 14:51:37 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 10:51:36 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: how would MA-Controller channel be impacted by suppression? Thread-Index: Ac+Eu28IWvKIWLxYQX2oXvR0ECMYXA== Date: Tue, 10 Jun 2014 14:51:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE7EF7@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.103.76] 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=BqQqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=hGb5DwchtBkA:10 a=ofMgfj31e3cA:10 a=4CCq8TzuqIwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Te_maBt7Z9-WLZgI0scA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/5oiHDC5xb4XwZg9HL-MsBFigfSU Subject: [lmap] how would MA-Controller channel be impacted by suppression? 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, 10 Jun 2014 14:51:51 -0000 Something that's been nagging at my brain is the idea that the communicatio= n between MA and Controller is a "task" (this been said during the suppress= ion flag discussions) that could potentially be suppressed. I thought that establishment of this communication was defined by a ma-chan= nel-obj that has its own timing info as to when to establish the connection= . And I didn't think it was possible to include a ma-channel-obj in the sup= pression list.=20 Going up the chain, to objects that point to ma-channel-obj, I don't see ho= w the following could be impacted by suppression: ma-preconfig-obj (which sets the ma-ma-to-controller-channel and the ma-ins= truction-channel) [BTW is there something that requires the ma-channel-targ= et of these 2 ma-channel-obj parameters to be the same, because both of the= se should be MA-Controller communication, just potentially with different t= iming? Currently it looks like there could be a separate "Controller" commu= nicated with for ma-to-controller instruction purposes but we said only one= Controller for a MA? Do we need 2?]=20 ma-config-obj (which can also set the ma-instruction-channel) ma-instruction-obj (which presumably gets updated or overwritten per the ma= -instruction-channel's connectivity and timing info) ma-status-obj (which uses the ma-ma-to-controller-channel?) It reads as if ma-log-obj (which relates to the logging of various info) ca= n be impacted by suppression, because logs are described as scheduled tasks= . But the lack of pointers between ma-log-obj and any other objects makes t= his very unclear. >From what I can see, only Measurement Tasks (ma-task-obj) and Schedules can= be directly impacted by Suppression, which will impact associated Reports = and logs. The MA will continue to communicate with the Controller at the Channel-spec= ified times and allow for updating of the Instruction and providing status. Or am I reading this wrong? Barbara From nobody Tue Jun 10 08:22:14 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 4677A1A0198 for ; Tue, 10 Jun 2014 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 C9UMOo82uQV9 for ; Tue, 10 Jun 2014 08:22:10 -0700 (PDT) Received: from p02c12o142.mxlogic.net (p02c12o142.mxlogic.net [208.65.145.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C991B281C for ; Tue, 10 Jun 2014 08:22:06 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o142.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id e9227935.2b9d2162e940.4941.00-599.13164.p02c12o142.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 09:22:06 -0600 (MDT) X-MXL-Hash: 5397229e6e544dd2-82b40f6ffa4af451f5eddcffdfa1ec3ca2961785 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o142.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id b2227935.0.2957.00-278.7762.p02c12o142.mxlogic.net (envelope-from ); Tue, 10 Jun 2014 09:20:12 -0600 (MDT) X-MXL-Hash: 5397222c6f5206e6-b90b2b6037ae09557573d332f431db36bcdd7c85 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 10:20:10 -0500 From: KEN KO To: "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: Measurement Methods and Tasks Thread-Index: Ac+BjgQhYak3zSu5Qbyp+rGKKmeQEwDHH2JgAADOIUAABFLqYA== Date: Tue, 10 Jun 2014 15:20:09 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130DE7EA1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE7EA1@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=M4DDKkAs c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=Pb0a8ExErrEA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=nVQTccOxHe9NO8cgfLsA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061013); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Qqf1_0zbeRmfaVKBZr6oeraS_KY Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 15:22:12 -0000 > I would prefer: > Measurement Task: The action performed by a particular Measurement > Agent that consists of the single operation of a Measurement Method > role at a particular time and with all of the role's Input Parameters set > to specific values. +1 to the above. > Alternately, we could go with Charles' approach and define > "Measurement Method" as "the role of a participating point in a > holistic measurement technique". Then the proposed definition > would be accurate. Personally, I think this may add to confusion, > because so many people already consider "Measurement Method" > to be the holistic technique.=20 I agree that this terminology would be confusing. I prefer the first altern= ative above. Ken From nobody Tue Jun 10 13:09:03 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 DF4E21A02FA for ; Tue, 10 Jun 2014 13:08:28 -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 ogs-7kYO7N8o for ; Tue, 10 Jun 2014 13:08:27 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3DE1A02D8 for ; Tue, 10 Jun 2014 13:07:52 -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 s5AK7hYZ025755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 14:07:44 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0DCF81E00AE; Tue, 10 Jun 2014 15:07:40 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id E832D1E005B; Tue, 10 Jun 2014 15:07:39 -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 s5AK7dCv017747; Tue, 10 Jun 2014 15:07:39 -0500 (CDT) Received: from [10.183.202.99] (x1069818.dhcp.intranet [10.183.202.99]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s5AK7clf017624; Tue, 10 Jun 2014 15:07:38 -0500 (CDT) Message-ID: <53976589.5080809@centurylink.com> Date: Tue, 10 Jun 2014 14:07:37 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: KEN KO , "STARK, BARBARA H" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130DE7EA1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: X-Enigmail-Version: 1.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/roI1YwMsijdhUxzK95I_X_VViIU Subject: Re: [lmap] Measurement Methods and Tasks 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, 10 Jun 2014 20:08:29 -0000 +1 On 6/10/2014 9:20 AM, KEN KO wrote: >> I would prefer: >> Measurement Task: The action performed by a particular Measurement >> Agent that consists of the single operation of a Measurement Method >> role at a particular time and with all of the role's Input Parameters set >> to specific values. > +1 to the above. > >> Alternately, we could go with Charles' approach and define >> "Measurement Method" as "the role of a participating point in a >> holistic measurement technique". Then the proposed definition >> would be accurate. Personally, I think this may add to confusion, >> because so many people already consider "Measurement Method" >> to be the holistic technique. > I agree that this terminology would be confusing. I prefer the first alternative above. > > Ken > > _______________________________________________ > 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 Wed Jun 11 05:29: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 BF82E1B2883 for ; Wed, 11 Jun 2014 05:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTShG0fina9s for ; Wed, 11 Jun 2014 05:29:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314AD1B2866 for ; Wed, 11 Jun 2014 05:29:01 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 11 Jun 2014 13:29:17 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 11 Jun 2014 13:28:58 +0100 From: To: , , , Date: Wed, 11 Jun 2014 13:28:58 +0100 Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hCAAVeqiA== Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C432EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/kjTK4HuIEFHwR7J-6OssPvqWXZk Subject: Re: [lmap] Suppression in 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: Wed, 11 Jun 2014 12:29:07 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C432EMV67UKRDdoma_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable i don't think that's the difference. Example: tasks 1,2,3 have flag can-be-suppressed tasks 4,5 have flag do-not-suppress General "Suppress" msg: suppresses 1,2,3 (no disagreement) "SUppress 2": suppresses 2 only (no disagreement) "Suppress 4": disagreement Barbara: it suppresses 4 Trevor: it throws an error XX: it suppresses 1,2,3,4 (dont think anyone has suggested this, but someon= e might argue for it) Also, "Unsuppress" I think there's an implicit agreement that there is just a simple unsuppres= s msg (which unsupresses any task that is suppressed) (ie no-one is suggesting also allowing an "Unsuppress 1" msg (that would un= suppress task 1 but leave other tasks suppressed) (I think we should only have the simple "Unsuppress" msg) ________________________________ From: KEN KO [KEN.KO@adtran.com] Sent: 10 June 2014 14:17 To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; charles.cook2@cent= urylink.com; lmap@ietf.org Subject: RE: [lmap] Suppression in framework Sorry if this is a duplicate =96 I had to reset my membership in the lmap l= ist. It seems that we are expressing two different interpretations of this flag,= and we need to converge on one. Definition =93A=94 What I proposed is a flag that *defines* the default suppression behavior o= f a task, e.g. in response to a basic suppress message. In that context, Tr= evor=92s first sentence has no meaning because the flags themselves define = the response to a basic suppress message =96 that is, there is nothing to o= verride. The MA interprets the basic suppression message as =93do what the = flag says=94 for each Task. If the flag is cleared, the task is suppressed = by default (using Phil=92s do-not-suppress polarity =96 I would reverse it,= but that=92s a minor point). If the flag is set, the task is not suppresse= d by default. Definition =93B=94 Trevor and Phil, I think (please correct me if this is wrong) you are inter= preting these flags as identifying exceptions to predefined default suppres= sion behavior. That is, if the flag is not set the suppression behavior con= forms to a fixed definition, but if the flag is set the Task is not suppres= sed. This is a one-way flag =96 there is no way to use it to change the def= ault behavior of a Task that is not normally suppressed. Is this understand= ing of your interpretation correct? For what it is worth, I favor =93A=94. I proposed it to resolve any ambigui= ty in the definition of Active vs. Passive as it applies to default suppres= sion behavior while allowing each operator to define that behavior on their= own terms. =93B=94 doesn=92t achieve either of those goals. Having said all that, I agree with you that communication with the Controll= er should never be suppressed. (I=92ve seen it listed several times as an e= xample of a critical task, but no other examples come to mind that aren=92t= recoverable via a new Instruction from the Controller.) So let us define c= ommunication with a Controller as always being exempt from suppression. The= MA is configured with the Controller=92s address so it is possible to mark= any Task communicating with that address as =93never suppress.=94 This mar= king can be done at configuration time (internally by the MA, no Instructio= n field required) so addresses don=92t need to be compared at run time. Ken From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Tuesday, June 10, 2014 4:27 AM To: philip.eardley@bt.com; charles.cook2@cent= urylink.com; KEN KO; lmap@ietf.org Subject: RE: [lmap] Suppression in framework The last bit is important =96 when we just send a basic suppress message (i= .e. default suppress everything) then this DOESN=92T over-ride the flags. I= wouldn=92t be in favour of reversing this when selected tasks/schedules ar= e listed. I think this would create confusion. Also I=92m in favour of not over-riding to give a bit more accidental prote= ction to critical tasks, such as communicating with the Controller. Remembe= r if we do want to over-ride any flags, the controller is free to either ch= ange those flags or remove the task from the schedules. So we always have t= he ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KE= N.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag =96 I don= =92t think this is very clean. There are some tasks (communication with con= troller) that would need to be marked as =91really do not suppress, even if= the optional msg says so=92. Perhaps also it would mean that the normal su= ppress and optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I=92m thinking primarily about communication wit= h the Controller. If we protect that, then suppression of anything else sho= uld be recoverable. And if that is true, I=92m still in favor of the option= al fields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning =93do-not-suppress this Measurement Ta= sk=94, my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says =93Suppress Task #213=94 then the MA= checks the do-not-suppress flag for Task #213 and either throws an error o= r doesn=92t start this Task. Similarly, if the Controller says =93Suppress = Schedule #49=94, then the MA checks the do-not-suppress flag for Tasks in t= his schedule and either throws an error or doesn=92t start any new Tasks in= this schedule. I=92ll tweak the text to say this (as well as removing the refs to Active). I=92ll also make clear that the Controller sets the do-not-suppress flag fo= r a Task (it isn=92t something that the MA decides about). Thanks phil _______________________________________________ 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[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCA= YAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1M= AAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf= 5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG= /V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+b= OMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI2= 7ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2= QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7= fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0Pcjhr= TLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am= 5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMk= dfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0= mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LEC= FWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube= 4GblQIAAAAASUVORK5CYII=3D] Fax: 925.281.06= 62[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACX= BIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb= 5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIv= kpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDI= iQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvc= AwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A= 7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kM= I8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+= YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyW= Q6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+= 1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+A= jmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/= 4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HApt= TsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVOR= K5CYII=3D] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCA= YAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1M= AAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf= 5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG= /V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+b= OMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI2= 7ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2= QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7= fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0Pcjhr= TLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am= 5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMk= dfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0= mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LEC= FWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube= 4GblQIAAAAASUVORK5CYII=3D] Fax: 925.281.06= 62[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACX= BIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb= 5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIv= kpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDI= iQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvc= AwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A= 7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kM= I8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+= YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyW= Q6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+= 1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+A= jmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/= 4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HApt= TsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVOR= K5CYII=3D] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCA= YAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1M= AAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf= 5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG= /V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+b= OMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI2= 7ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2= QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7= fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0Pcjhr= TLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am= 5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMk= dfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0= mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LEC= FWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube= 4GblQIAAAAASUVORK5CYII=3D] Fax: 925.281.06= 62[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACX= BIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb= 5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIv= kpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDI= iQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvc= AwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A= 7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kM= I8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+= YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyW= Q6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+= 1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+A= jmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/= 4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HApt= TsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVOR= K5CYII=3D] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCA= YAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1M= AAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf= 5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG= /V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+b= OMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI2= 7ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2= QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7= fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0Pcjhr= TLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am= 5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMk= dfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0= mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LEC= FWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube= 4GblQIAAAAASUVORK5CYII=3D] Fax: 925.281.06= 62[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACX= BIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb= 5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIv= kpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDI= iQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvc= AwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A= 7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kM= I8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+= YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyW= Q6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+= 1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+A= jmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/= 4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HApt= TsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVOR= K5CYII=3D] charles.cook2@centurylink.com --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C432EMV67UKRDdoma_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
i don't think that's the difference.
 
Example:
tasks 1,2,3 have flag can-be-suppressed
tasks 4,5 have flag do-not-suppress
 
General "Suppress" msg: suppresses 1,2= ,3 (no disagreement)
 
"SUppress 2": suppresses 2 only (no di= sagreement)
 
"Suppress 4":
disagreement
Barbara: it suppresses 4
Trevor: it throws an error
XX: it suppresses 1,2,3,4 (dont think anyone has= suggested this, but someone might argue for it)
 
Also,
"Unsuppress"
I think there's an implicit agreement that there= is just a simple unsuppress msg (which unsupresses any task that is suppre= ssed)
(ie no-one is suggesting also allowing an "= Unsuppress 1" msg (that would unsuppress task 1 but leave other tasks = suppressed)
(I think we should only have the simple "Un= suppress" msg)
=  
From: KEN KO [KEN= .KO@adtran.com]
Sent: 10 June 2014 14:17
To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; charles.coo= k2@centurylink.com; lmap@ietf.org
Subject: RE: [lmap] Suppression in framework

Sorry if this is a du= plicate =96 I had to reset my membership in the lmap list.

 

It seems that we are = expressing two different interpretations of this flag, and we need to conve= rge on one.

 

Definition =93A=94

What I proposed is a = flag that *defines* the default suppression behavior of a task, e.g.= in response to a basic suppress message. In that context, Trevor=92s first= sentence has no meaning because the flags themselves define the response to a basic suppress message =96 that is, th= ere is nothing to override. The MA interprets the basic suppression message= as =93do what the flag says=94 for each Task. If the flag is cleared, the = task is suppressed by default (using Phil=92s do-not-suppress polarity =96 I would reverse it, but that=92s a minor poin= t). If the flag is set, the task is not suppressed by default.

 

Definition =93B=94

Trevor and Phil, I th= ink (please correct me if this is wrong) you are interpreting these flags a= s identifying exceptions to predefined default suppression behavior. That i= s, if the flag is not set the suppression behavior conforms to a fixed definition, but if the flag is set the Task i= s not suppressed. This is a one-way flag =96 there is no way to use it to c= hange the default behavior of a Task that is not normally suppressed. Is th= is understanding of your interpretation correct?

 

For what it is worth,= I favor =93A=94. I proposed it to resolve any ambiguity in the definition = of Active vs. Passive as it applies to default suppression behavior while a= llowing each operator to define that behavior on their own terms. =93B=94 doesn=92t achieve either of those goals.

 

Having said all that,= I agree with you that communication with the Controller should never be su= ppressed. (I=92ve seen it listed several times as an example of a critical = task, but no other examples come to mind that aren=92t recoverable via a new Instruction from the Controller.) So l= et us define communication with a Controller as always being exempt from su= ppression. The MA is configured with the Controller=92s address so it is po= ssible to mark any Task communicating with that address as =93never suppress.=94 This marking can be done at con= figuration time (internally by the MA, no Instruction field required) so ad= dresses don=92t need to be compared at run time.

 

Ken

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, June 10, 2014 4:27 AM
To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN KO; lmap@ietf.org
Subject: RE: [lmap] Suppression in framework

 

The last bit is important =96 when we just send a basi= c suppress message (i.e. default suppress everything) then this DOESN=92T o= ver-ride the flags. I wouldn=92t be in favour of reversing this when selected tasks/schedules are listed. I think this w= ould create confusion.

 

Also I=92m in favour of not over-riding to give a bit = more accidental protection to critical tasks, such as communicating with th= e Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove t= he task from the schedules. So we always have the ability to switch off any= task.

 

Trevor.

 

 

From: lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 10 June 2014 09:21
To: charles.cook2@c= enturylink.com; KEN.KO@adtran.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My ta= ke is that the do-not-suppress flag should not be defined in the Measuremen= t Method. The controller should be able to set it. for some operators of measurement systems a particular method m= ay be critical, for some it may be highly optional.

 

Allow= ing the optional msg to over-ride the do-not-suppress flag =96 I don=92t th= ink this is very clean. There are some tasks (communication with controller) that would need to be marked as =91really = do not suppress, even if the optional msg says so=92. Perhaps also it would= mean that the normal suppress and optional suppress msgs would have to be = processed differently.

 

 

 

From: Charles Cook [mailto:charles.cook2@centurylink.com]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

As soon as I hit send, that thought occurred to me as = well, and whether it would be out of scope. 

Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller.  The Network o= wner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Meth= od.

I think I am convinced that maybe this is better handled by an agreement be= tween parties.

Charles

On 6= /9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do t= he right thing, then there seems to be little value in a flag in the Measur= ement Method that prohibits doing the wrong thing.

 

Perhaps if that is the case, this is better handled by= an agreement between parties that would be out of scope for lmap?

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Good point.  Or the Controller can do the configu= ration manipulation in the creation of the Measurement Task (my preference)= so the MA does not have to.  - keep the MA as simple as possible at t= he expense of the Controller.

Charles

On= 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can se= e some utility in that, but it does complicate the MA which would have to t= est suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On 6= /9/2014 12:19 PM, KEN KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag = from redefining the default suppression behavior suggested for a particular= Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like t= hat would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:char= les.cook2@centurylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Cont= roller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On= 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the o= ption fields already override default behavior.

 

Given the more general nature of Tasks as you point = out, there may be specific tasks which should simply never be suppressed, e= ither by default configuration or optional field. I=92m thinking primarily about communication with the Controller. I= f we protect that, then suppression of anything else should be recoverable.= And if that is true, I=92m still in favor of the optional fields overridin= g the default.

 

Your thoughts?

 

From:= philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Ove= r-ride might make it a bit too easy to accidentally suppress a really cruci= al Task such as reporting to the collector or communication with the controller (since tasks are now general and not = just measurement tasks).  Or deliberately by an attacker.

 

If = the controller wants to suppress a task with the do-not-suppress flag set, = then it would either re-does the task configuration or it updates the schedule

 

From:= KEN KO [mailto:KEN.KO@adt= ran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppr= ess fields would override the default behavior flag. That is, if the do-not= -suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule = containing the Task), the task would then be suppressed and no error would = be thrown.

 

 

From:= lmap [mailto:lmap-bou= nces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework=

 

So we have agree= d to modify suppression so the default behaviour is that tasks have a Boole= an flag which indicates whether or not a Suppress message will suppress them.

Question: what d= o we want the impact of the flag to be when we have the more complex, optio= nal Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

 

Treating the Boo= lean flag as meaning =93do-not-suppress this Measurement Task=94, my propos= al is to basically keep the current text unaltered:

  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

<< Optionally the Suppression information may

   include:

 

   o  a set of Measurement Tasks to suppres= s; the others are not

      suppressed.  For examp= le, this could be useful if a particular=

      Measurement Task is overloa= ding a Measurement Peer.

 

   o  a set of Measurement Schedules to sup= press; the others are not

      suppressed.  For examp= le, suppose the measurement system has

      defined two Schedules, one = with the most critical Measurement

      Tasks and the other with le= ss critical ones that create a lot of

      Active Measurement Traffic,= then it may only want to suppress the

      second.

 

   o  a start time, at which suppression be= gins

 

   o  an end time, at which suppression end= s

 

   o  a demand that the MA ends its on-goin= g Active Measurement Task(s)

      (and deletes the associated= partial Measurement Result(s)).

>> 

 

In other words, = if the Controller says =93Suppress Task #213=94 then the MA checks the do-n= ot-suppress flag for Task #213 and either throws an error or doesn=92t start this Task. Similarly, if the Controller says = =93Suppress Schedule #49=94, then the MA checks the do-not-suppress flag fo= r Tasks in this schedule and either throws an error or doesn=92t start any = new Tasks in this schedule.

 

I=92ll tweak the= text to say this (as well as removing the refs to Active).

I=92ll also make= clear that the Controller sets the do-not-suppress flag for a Task (it isn= =92t something that the MA decides about).

 

Thanks

phil




____________________=
___________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/m=
ailman/listinfo/lmap



-- 
 
Charles Cook =

Principal Architect<=
/span>
Network
5325 Zuni Street; Su=
ite 224
Denver, CO  802=
21
Tel:  3=
03.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- 
 
Charles Cook 

Principal Architect


Network


5325 Zuni Street; Suit=
e 224


Denver, CO  80221=



Tel:  303=
.992.8952<=
/span>  Fax:  925.281.0662


charles.cook2@centurylink.com

 

-- 
 
Charles Cook =

Principal Architect<=
/span>
Network
5325 Zuni Street; Su=
ite 224
Denver, CO  802=
21
Tel:  3=
03.992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com

 

-- 
 
Charles Cook 

Principal Architect


Network


5325 Zuni Street; Suit=
e 224


Denver, CO  80221=



Tel:  303=
.992.8952<=
/span>  Fax:  925.281.0662


charles.cook2@centurylink.com
--_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C432EMV67UKRDdoma_-- From nobody Wed Jun 11 05:34:13 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 3DF151B27B7 for ; Wed, 11 Jun 2014 05:34:12 -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 WgDFKgullwFL for ; Wed, 11 Jun 2014 05:34:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696E31ACAD6 for ; Wed, 11 Jun 2014 05:34:09 -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.181.6; Wed, 11 Jun 2014 13:29:59 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 11 Jun 2014 13:33:35 +0100 From: To: , Date: Wed, 11 Jun 2014 13:29:40 +0100 Thread-Topic: how would MA-Controller channel be impacted by suppression? Thread-Index: Ac+Eu28IWvKIWLxYQX2oXvR0ECMYXAAtWHj4 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DE7EF7@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE7EF7@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/EF3Ek-XGiXpz7fPK7j-4FWK7flY Subject: Re: [lmap] how would MA-Controller channel be impacted by suppression? 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, 11 Jun 2014 12:34:12 -0000 i think you're reading this right - think the gap is that the information m= odel i-d needs an update they should all be tasks with schedules incidentally, also suggestion is (will be) to merge config and bootstrap in= to single object (since they affect the same info) phil ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H [bs7652@at= t.com] Sent: 10 June 2014 15:51 To: lmap@ietf.org Subject: [lmap] how would MA-Controller channel be impacted by suppression? Something that's been nagging at my brain is the idea that the communicatio= n between MA and Controller is a "task" (this been said during the suppress= ion flag discussions) that could potentially be suppressed. I thought that establishment of this communication was defined by a ma-chan= nel-obj that has its own timing info as to when to establish the connection= . And I didn't think it was possible to include a ma-channel-obj in the sup= pression list. Going up the chain, to objects that point to ma-channel-obj, I don't see ho= w the following could be impacted by suppression: ma-preconfig-obj (which sets the ma-ma-to-controller-channel and the ma-ins= truction-channel) [BTW is there something that requires the ma-channel-targ= et of these 2 ma-channel-obj parameters to be the same, because both of the= se should be MA-Controller communication, just potentially with different t= iming? Currently it looks like there could be a separate "Controller" commu= nicated with for ma-to-controller instruction purposes but we said only one= Controller for a MA? Do we need 2?] ma-config-obj (which can also set the ma-instruction-channel) ma-instruction-obj (which presumably gets updated or overwritten per the ma= -instruction-channel's connectivity and timing info) ma-status-obj (which uses the ma-ma-to-controller-channel?) It reads as if ma-log-obj (which relates to the logging of various info) ca= n be impacted by suppression, because logs are described as scheduled tasks= . But the lack of pointers between ma-log-obj and any other objects makes t= his very unclear. >From what I can see, only Measurement Tasks (ma-task-obj) and Schedules ca= n be directly impacted by Suppression, which will impact associated Reports= and logs. The MA will continue to communicate with the Controller at the Channel-spec= ified times and allow for updating of the Instruction and providing status. Or am I reading this wrong? Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From nobody Wed Jun 11 05:36: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 5FA241B27B7 for ; Wed, 11 Jun 2014 05:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZI2VFMG78vG for ; Wed, 11 Jun 2014 05:36:18 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BCC1ACAD6 for ; Wed, 11 Jun 2014 05:36:17 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 14d48935.2b103c20c940.108078.00-541.211101.p01c12o148.mxlogic.net (envelope-from ); Wed, 11 Jun 2014 06:36:17 -0600 (MDT) X-MXL-Hash: 53984d417fd0ce25-59c6411e926b697dc6c2b844dfa3e5cd81d8b95c Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 23d48935.0.107803.00-272.210525.p01c12o148.mxlogic.net (envelope-from ); Wed, 11 Jun 2014 06:36:05 -0600 (MDT) X-MXL-Hash: 53984d3535fa4562-5f67d114c5da271177ecbb373e960c4bcdfa7673 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 07:36:01 -0500 From: KEN KO To: "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hCAAVeqiP///YkQ Date: Wed, 11 Jun 2014 12:36:01 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77757117Fexmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=V93z0IXi c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=J_N6KFswAAAA:] X-AnalysisOut: [8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=rUt6GBLmAAAA:8 a=55p] X-AnalysisOut: [KmRkH1wRT6BEIfgcA:9 a=vhEFNgGSZ1-sDH5m:21 a=OOOpyFRqfnxLKm] X-AnalysisOut: [_9:21 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:1] X-AnalysisOut: [0 a=DvnSUQUdWHYA:10 a=Pwbduc0PQ3sA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [W1qU_X6G3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=fRXZEd] X-AnalysisOut: [cETS6b4P8TnSsA:9 a=k6EZ8wUmoA5BNz59:21 a=Onuq__H3nx22VJ4O:] X-AnalysisOut: [21 a=uT9kx-m8LnpvmzgS:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:] X-AnalysisOut: [10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061106); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/c_U3Qf3aXDKI0L9Y4IHznK30Up0 Subject: Re: [lmap] Suppression in 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: Wed, 11 Jun 2014 12:36:25 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757117Fexmb1corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline ... i don't think that's the difference. Example: tasks 1,2,3 have flag can-be-suppressed tasks 4,5 have flag do-not-suppress General "Suppress" msg: suppresses 1,2,3 (no disagreement) "SUppress 2": suppresses 2 only (no disagreement) I agree with everything above. "Suppress 4": disagreement Barbara: it suppresses 4 Trevor: it throws an error XX: it suppresses 1,2,3,4 (dont think anyone has suggested this, but someon= e might argue for it) I agree with Barbara. (And I hope no one argues for XX!) Also, "Unsuppress" I think there's an implicit agreement that there is just a simple unsuppres= s msg (which unsupresses any task that is suppressed) (ie no-one is suggesting also allowing an "Unsuppress 1" msg (that would un= suppress task 1 but leave other tasks suppressed) (I think we should only have the simple "Unsuppress" msg) Agreed. ________________________________ From: KEN KO [KEN.KO@adtran.com] Sent: 10 June 2014 14:17 To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; charles.cook2@cent= urylink.com; lmap@ietf.org Subject: RE: [lmap] Suppression in framework Sorry if this is a duplicate - I had to reset my membership in the lmap lis= t. It seems that we are expressing two different interpretations of this flag,= and we need to converge on one. Definition "A" What I proposed is a flag that *defines* the default suppression behavior o= f a task, e.g. in response to a basic suppress message. In that context, Tr= evor's first sentence has no meaning because the flags themselves define th= e response to a basic suppress message - that is, there is nothing to overr= ide. The MA interprets the basic suppression message as "do what the flag s= ays" for each Task. If the flag is cleared, the task is suppressed by defau= lt (using Phil's do-not-suppress polarity - I would reverse it, but that's = a minor point). If the flag is set, the task is not suppressed by default. Definition "B" Trevor and Phil, I think (please correct me if this is wrong) you are inter= preting these flags as identifying exceptions to predefined default suppres= sion behavior. That is, if the flag is not set the suppression behavior con= forms to a fixed definition, but if the flag is set the Task is not suppres= sed. This is a one-way flag - there is no way to use it to change the defau= lt behavior of a Task that is not normally suppressed. Is this understandin= g of your interpretation correct? For what it is worth, I favor "A". I proposed it to resolve any ambiguity i= n the definition of Active vs. Passive as it applies to default suppression= behavior while allowing each operator to define that behavior on their own= terms. "B" doesn't achieve either of those goals. Having said all that, I agree with you that communication with the Controll= er should never be suppressed. (I've seen it listed several times as an exa= mple of a critical task, but no other examples come to mind that aren't rec= overable via a new Instruction from the Controller.) So let us define commu= nication with a Controller as always being exempt from suppression. The MA = is configured with the Controller's address so it is possible to mark any T= ask communicating with that address as "never suppress." This marking can b= e done at configuration time (internally by the MA, no Instruction field re= quired) so addresses don't need to be compared at run time. Ken From: trevor.burbridge@bt.com [mailto:trevo= r.burbridge@bt.com] Sent: Tuesday, June 10, 2014 4:27 AM To: philip.eardley@bt.com; charles.cook2@cent= urylink.com; KEN KO; lmap@ietf.org Subject: RE: [lmap] Suppression in framework The last bit is important - when we just send a basic suppress message (i.e= . default suppress everything) then this DOESN'T over-ride the flags. I wou= ldn't be in favour of reversing this when selected tasks/schedules are list= ed. I think this would create confusion. Also I'm in favour of not over-riding to give a bit more accidental protect= ion to critical tasks, such as communicating with the Controller. Remember = if we do want to over-ride any flags, the controller is free to either chan= ge those flags or remove the task from the schedules. So we always have the= ability to switch off any task. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 10 June 2014 09:21 To: charles.cook2@centurylink.com; KE= N.KO@adtran.com; lmap@ietf.org Subject: Re: [lmap] Suppression in framework My take is that the do-not-suppress flag should not be defined in the Measu= rement Method. The controller should be able to set it. for some operators = of measurement systems a particular method may be critical, for some it may= be highly optional. Allowing the optional msg to over-ride the do-not-suppress flag - I don't t= hink this is very clean. There are some tasks (communication with controlle= r) that would need to be marked as 'really do not suppress, even if the opt= ional msg says so'. Perhaps also it would mean that the normal suppress and= optional suppress msgs would have to be processed differently. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 09 June 2014 21:43 To: KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Suppression in framework As soon as I hit send, that thought occurred to me as well, and whether it = would be out of scope. Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller. The Network owner = certainly would not be precluded from designing its MAs to perform such a t= est against the Measurement Method. I think I am convinced that maybe this is better handled by an agreement be= tween parties. Charles On 6/9/2014 2:27 PM, KEN KO wrote: But if a third party Controller can be trusted to do the right thing, then = there seems to be little value in a flag in the Measurement Method that pro= hibits doing the wrong thing. Perhaps if that is the case, this is better handled by an agreement between= parties that would be out of scope for lmap? From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 4:16 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Good point. Or the Controller can do the configuration manipulation in the= creation of the Measurement Task (my preference) so the MA does not have t= o. - keep the MA as simple as possible at the expense of the Controller. Charles On 6/9/2014 1:35 PM, KEN KO wrote: OK, thanks. I read it wrong the first time. I can see some utility in that,= but it does complicate the MA which would have to test suppression configu= ration in the Task against what is allowed by the Measurement Method. From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 3:15 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Ken, I'm not sure I follow your question. If there is a Measurement Method that= has been defined a priori such that the Suppression behavior defined in th= e Measurement Method is not to be over-written, there should be a flag set = to indicate that the Suppression behavior cannot be modified. In other wor= ds, if the defined suppression behavior is permitted to be changed, a flag = in the Measurement Method would be set to Suppression_Behavior_Modifiable := True. A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork. It is possible that the owner of a Network could create a registry = of Measurement Methods that are allowable on their Network by third parties= that are using a third-party Controller to measure portions of the owner'= s Network. The owner of the Network may determine that within the set of M= easurement Methods, there may be a subset of Measurement Methods that the N= etwork Owner always wants to be suppressed when a suppression is sent, and = does not want the third-party Controller to ever override that behavior. If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression. Charles On 6/9/2014 12:19 PM, KEN KO wrote: Charles, Is there a reason to prevent the do-not-suppress flag from redefining the d= efault suppression behavior suggested for a particular Measurement Method i= n a Registry, yet still allow it to be overridden by the optional suppressi= on fields? Seems like that would be a needless limitation on the informatio= n model. Ken From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: Monday, June 09, 2014 2:00 PM To: KEN KO; philip.eardley@bt.com; lmap@ietf.= org Subject: Re: [lmap] Suppression in framework Regarding suppression (not communication with the Controller): My take is that the default suppression behavior can be coded into the Meas= urement Method. If there is a possibility that the default can be overwrit= ten, then an optional field is added to the Measurement Method. If the Con= troller wants to override the default, it must assert the optional override= field when generating the Measurement Task. I have not formed an opinion regarding MA communication with the Controller= . Charles On 6/9/2014 11:05 AM, KEN KO wrote: My interpretation of the existing text is that the option fields already ov= erride default behavior. Given the more general nature of Tasks as you point out, there may be speci= fic tasks which should simply never be suppressed, either by default config= uration or optional field. I'm thinking primarily about communication with = the Controller. If we protect that, then suppression of anything else shoul= d be recoverable. And if that is true, I'm still in favor of the optional f= ields overriding the default. Your thoughts? From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, June 09, 2014 12:56 PM To: KEN KO; lmap@ietf.org Subject: RE: Suppression in framework Over-ride might make it a bit too easy to accidentally suppress a really cr= ucial Task such as reporting to the collector or communication with the con= troller (since tasks are now general and not just measurement tasks). Or d= eliberately by an attacker. If the controller wants to suppress a task with the do-not-suppress flag se= t, then it would either re-does the task configuration or it updates the sc= hedule From: KEN KO [mailto:KEN.KO@adtran.com] Sent: 09 June 2014 17:49 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: Suppression in framework I would think that information in the optional Suppress fields would overri= de the default behavior flag. That is, if the do-not-suppress flag was set = for a given task, yet a Suppression message specifically listed that same t= ask (or schedule containing the Task), the task would then be suppressed an= d no error would be thrown. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Monday, June 09, 2014 12:43 PM To: lmap@ietf.org Subject: [lmap] Suppression in framework So we have agreed to modify suppression so the default behaviour is that ta= sks have a Boolean flag which indicates whether or not a Suppress message w= ill suppress them. Question: what do we want the impact of the flag to be when we have the mor= e complex, optional Suppress message? (it lists specific Tasks or Schedules= for suppression.) http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 Treating the Boolean flag as meaning "do-not-suppress this Measurement Task= ", my proposal is to basically keep the current text unaltered: << Optionally the Suppression information may include: o a set of Measurement Tasks to suppress; the others are not suppressed. For example, this could be useful if a particular Measurement Task is overloading a Measurement Peer. o a set of Measurement Schedules to suppress; the others are not suppressed. For example, suppose the measurement system has defined two Schedules, one with the most critical Measurement Tasks and the other with less critical ones that create a lot of Active Measurement Traffic, then it may only want to suppress the second. o a start time, at which suppression begins o an end time, at which suppression ends o a demand that the MA ends its on-going Active Measurement Task(s) (and deletes the associated partial Measurement Result(s)). >> In other words, if the Controller says "Suppress Task #213" then the MA che= cks the do-not-suppress flag for Task #213 and either throws an error or do= esn't start this Task. Similarly, if the Controller says "Suppress Schedule= #49", then the MA checks the do-not-suppress flag for Tasks in this schedu= le and either throws an error or doesn't start any new Tasks in this schedu= le. I'll tweak the text to say this (as well as removing the refs to Active). I'll also make clear that the Controller sets the do-not-suppress flag for = a Task (it isn't something that the MA decides about). Thanks phil _______________________________________________ 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[http://portal.mxlogic.com/images/transparent.gif] Fax: 925.281.0662[http://portal.mxlogic.com/image= s/transparent.gif] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[http://portal.mxlogic.com/images/transparent.gif] Fax: 925.281.0662[http://portal.mxlogic.com/image= s/transparent.gif] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[http://portal.mxlogic.com/images/transparent.gif] Fax: 925.281.0662[http://portal.mxlogic.com/image= s/transparent.gif] charles.cook2@centurylink.com -- Charles Cook Principal Architect Network 5325 Zuni Street; Suite 224 Denver, CO 80221 Tel: 303.992.8952[http://portal.mxlogic.com/images/transparent.gif] Fax: 925.281.0662[http://portal.mxlogic.com/image= s/transparent.gif] charles.cook2@centurylink.com --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757117Fexmb1corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline …

 

i don't think= that's the difference.

 

Example:=

tasks 1,2,3 h= ave flag can-be-suppressed

tasks 4,5 hav= e flag do-not-suppress

 

General "= ;Suppress" msg: suppresses 1,2,3 (no disagreement)

 

"SUppres= s 2": suppresses 2 only (no disagreement)

 

I agree with everythin= g above.

 

"Suppres= s 4":

disagreement<= o:p>

Barbara: it s= uppresses 4

Trevor: it th= rows an error

XX: it suppre= sses 1,2,3,4 (dont think anyone has suggested this, but someone might argue= for it)

 

I agree with Barbara. = (And I hope no one argues for XX!)

 

Also,

"Unsuppr= ess"

I think there= 's an implicit agreement that there is just a simple unsuppress msg (which = unsupresses any task that is suppressed)

(ie no-one is= suggesting also allowing an "Unsuppress 1" msg (that would unsup= press task 1 but leave other tasks suppressed)

(I think we s= hould only have the simple "Unsuppress" msg)

 

Agreed.

 

From: KEN KO [KEN.KO@adtran.com]
Sent: 10 June 2014 14:17
To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; charles.cook2@centurylink.com; lmap@ie= tf.org
Subject: RE: [lmap] Suppression in framework

Sorry if this is a duplicate – I had to reset my membership in t= he lmap list.

 

It seems that we are expressing two different interpretations of this = flag, and we need to converge on one.

 

Definition “A”

What I proposed is a flag that *defines* the default suppressio= n behavior of a task, e.g. in response to a basic suppress message. In that= context, Trevor’s first sentence has no meaning because the flags themselves define the response to a basic sup= press message – that is, there is nothing to override. The MA interpr= ets the basic suppression message as “do what the flag says” fo= r each Task. If the flag is cleared, the task is suppressed by default (using Phil’s do-not-suppress polarity – I would re= verse it, but that’s a minor point). If the flag is set, the task is = not suppressed by default.

 

Definition “B”

Trevor and Phil, I think (please correct me if this is wrong) you are = interpreting these flags as identifying exceptions to predefined default su= ppression behavior. That is, if the flag is not set the suppression behavior conforms to a fixed definition, but if= the flag is set the Task is not suppressed. This is a one-way flag –= there is no way to use it to change the default behavior of a Task that is= not normally suppressed. Is this understanding of your interpretation correct?

 

For what it is worth, I favor “A”. I proposed it to resolv= e any ambiguity in the definition of Active vs. Passive as it applies to de= fault suppression behavior while allowing each operator to define that behavior on their own terms. “B” doesn’t = achieve either of those goals.

 

Having said all that, I agree with you that communication with the Con= troller should never be suppressed. (I’ve seen it listed several time= s as an example of a critical task, but no other examples come to mind that aren’t recoverable via a new Instruction = from the Controller.) So let us define communication with a Controller as a= lways being exempt from suppression. The MA is configured with the Controll= er’s address so it is possible to mark any Task communicating with that address as “never suppress.” = This marking can be done at configuration time (internally by the MA, no In= struction field required) so addresses don’t need to be compared at r= un time.

 

Ken

 

From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, June 10, 2014 4:27 AM
To: philip.eardley@bt.com; charles.cook2@centurylink.com; KEN KO; lmap@ietf.org
Subject: RE: [lmap] Suppression in framework

 

The last bit is important – when we just send a = basic suppress message (i.e. default suppress everything) then this DOESN&#= 8217;T over-ride the flags. I wouldn’t be in favour of reversing this when selected tasks/schedules are listed. I think this w= ould create confusion.

 

Also I’m in favour of not over-riding to give a = bit more accidental protection to critical tasks, such as communicating wit= h the Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove t= he task from the schedules. So we always have the ability to switch off any= task.

 

Trevor.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: 10 June 2014 09:21
To: charles.cook2@c= enturylink.com; KEN.KO@adtran.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

My take is that the do-not-suppress flag should not be defined = in the Measurement Method. The controller should be able to set it. for some operators of measurement systems a particular method may be c= ritical, for some it may be highly optional.

 

Allowing the optional msg to over-ride the do-not-suppress flag= – I don’t think this is very clean. There are some tasks (comm= unication with controller) that would need to be marked as ‘really do not supp= ress, even if the optional msg says so’. Perhaps also it would mean t= hat the normal suppress and optional suppress msgs would have to be process= ed differently.

 

 

 

 

As soon as I hit send, that thought occurred to me as = well, and whether it would be out of scope. 

Your comment on the MA having to test the configuration against what is all= owed by the Measurement Method may be more trust worthy from the perspectiv= e of the Network owner than the third-party Controller.  The Network o= wner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Meth= od.

I think I am convinced that maybe this is better handled by an agreement be= tween parties.

Charles

On = 6/9/2014 2:27 PM, KEN KO wrote:

But if a third party Controller can be trusted to do t= he right thing, then there seems to be little value in a flag in the Measur= ement Method that prohibits doing the wrong thing.

 

Perhaps if that is the case, this is better handled by= an agreement between parties that would be out of scope for lmap?

 

From: Charles Cook [mailto:charles.cook2@cen= turylink.com]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Good point.  Or the Controller can do the configu= ration manipulation in the creation of the Measurement Task (my preference)= so the MA does not have to.  - keep the MA as simple as possible at t= he expense of the Controller.

Charles

On = 6/9/2014 1:35 PM, KEN KO wrote:

OK, thanks. I read it wrong the first time. I can see = some utility in that, but it does complicate the MA which would have to tes= t suppression configuration in the Task against what is allowed by the Measurement Method.

 

From: Charles Cook [mailto:charles.cook2@cen= turylink.com]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Ken,

I'm not sure I follow your question.  If there is a Measurement Method= that has been defined a priori such that the Suppression behavior defined = in the Measurement Method is not to be over-written, there should be a flag= set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppress= ion behavior is permitted to be changed, a flag in the Measurement Method w= ould be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control = of what third-parties do relative to Suppression behavior on the owner's Ne= twork.  It is possible that the owner of a Network could create a regi= stry of Measurement Methods that are allowable on their Network by third parties that are using  a third-p= arty Controller to measure portions of the owner's Network.  The owner= of the Network may determine that within the set of Measurement Methods, t= here may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is= sent, and does not want the third-party Controller to ever override that b= ehavior.

If the Network owner also owns the Controller, then I can't think of a good= reason to consider this method of dealing with Suppression.

Charles

On = 6/9/2014 12:19 PM, KEN KO wrote:

Charles,

 

Is there a reason to prevent the do-not-suppress flag = from redefining the default suppression behavior suggested for a particular= Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like t= hat would be a needless limitation on the information model.

 

Ken

 

From: Charles Cook [mailto:charles.cook2@cen= turylink.com]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; philip.eardley@= bt.com; lmap@ietf.org
Subject: Re: [lmap] Suppression in framework

 

Regarding suppression (not communication with the Cont= roller):
My take is that the default suppression behavior can be coded into the Meas= urement Method.  If there is a possibility that the default can be ove= rwritten, then an optional field is added to the Measurement Method.  = If the Controller wants to override the default, it must assert the optional override field when generating the Measurement= Task.

I have not formed an opinion regarding MA communication with the Controller= .

Charles

On = 6/9/2014 11:05 AM, KEN KO wrote:

My interpretation of the existing text is that the opt= ion fields already override default behavior.

 

Given the more general nature of Tasks as you point ou= t, there may be specific tasks which should simply never be suppressed, eit= her by default configuration or optional field. I’m thinking primarily about communication with the Controlle= r. If we protect that, then suppression of anything else should be recovera= ble. And if that is true, I’m still in favor of the optional fields o= verriding the default.

 

Your thoughts?

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; lmap@ietf.org
Subject: RE: Suppression in framework

 

Over-ride might make it a bit too easy to accidentally suppress= a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement = tasks).  Or deliberately by an attacker.

 

If the controller wants to suppress a task with the do-not-supp= ress flag set, then it would either re-does the task configuration or it updates the schedule

 

From: KEN KO [mailto:KEN.KO@adtran.com]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: Suppression in framework

 

I would think that information in the optional Suppres= s fields would override the default behavior flag. That is, if the do-not-s= uppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule cont= aining the Task), the task would then be suppressed and no error would be t= hrown.

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Monday, June 09, 2014 12:43 PM
To: lmap@ietf.org
Subject: [lmap] Suppression in framework

 

So we have agreed to modify suppression so the default behaviour is that t= asks have a Boolean flag which indicates whether or not a Suppress message will suppress them.

Question: what do we want the impact of the flag to be when we have the mo= re complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)  

http://tools.ietf.org/html/draft-ietf-lmap-framework-05= #page-15

 

Treating the Boolean flag as meaning “do-not-suppress this Measureme= nt Task”, my proposal is to basically keep the current text unaltered= :

            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;          

<<<=
/span> Optionally the Suppression information may<=
/span>

   include:

 

   o  a set of Measurement Tasks to s= uppress; the others are not

      suppressed.  For= example, this could be useful if a particular

      Measurement Task is o= verloading a Measurement Peer.

 

   o  a set of Measurement Schedules = to suppress; the others are not

      suppressed.  For= example, suppose the measurement system has

      defined two Schedules= , one with the most critical Measurement

      Tasks and the other w= ith less critical ones that create a lot of

      Active Measurement Tr= affic, then it may only want to suppress the

      second.

 

   o  a start time, at which suppress= ion begins

 

   o  an end time, at which suppressi= on ends

 

   o  a demand that the MA ends its o= n-going Active Measurement Task(s)

      (and deletes the asso= ciated partial Measurement Result(s)).

>> 

 

In other words, if the Controller says “Suppress Task #213” th= en the MA checks the do-not-suppress flag for Task #213 and either throws a= n error or doesn’t start this Task. Similarly, if the Controller says = “Suppress Schedule #49”, then the MA checks the do-not-suppress= flag for Tasks in this schedule and either throws an error or doesn’= t start any new Tasks in this schedule.

 

I’ll tweak the text to say this (as well as removing the refs to Act= ive).

I’ll also make clear that the Controller sets the do-not-suppress fl= ag for a Task (it isn’t something that the MA decides about).<= o:p>

 

Thanks

phil





_____________________=
__________________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/lmap




-- =

 
Charles Cook <=
o:p>
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.8952  Fax:  925.281.0662=

charles.cook2@centurylink.com

 

-- =

 
Charles Cook <=
o:p>
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.8952  Fax:  925.281.0662=

charles.cook2@centurylink.com

 

-- =

 
Charles Cook <=
o:p>
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.8952  Fax:  925.281.0662=

charles.cook2@centurylink.com

 

-- =

 
Charles Cook <=
o:p>
Principal Architect
Network
5325 Zuni Street; Sui=
te 224
Denver, CO  8022=
1
Tel:  303.992.8952  Fax:  925.281.0662=

charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB77757117Fexmb1corpadtran_-- From nobody Wed Jun 11 06:38:28 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 7780E1A0088 for ; Wed, 11 Jun 2014 06:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RP_MATCHES_RCVD=-0.651] 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 yEVEaGoY4iBx for ; Wed, 11 Jun 2014 06:38:23 -0700 (PDT) Received: from fly-neu.RZ.HS-Augsburg.DE (fly-neu.RZ.HS-Augsburg.DE [IPv6:2001:638:102:2::217:48]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7461A00DA for ; Wed, 11 Jun 2014 06:38:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fly-neu.RZ.HS-Augsburg.DE (Postfix) with ESMTP id 949021D6031; Wed, 11 Jun 2014 15:38:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de Received: from fly-neu.RZ.HS-Augsburg.DE ([127.0.0.1]) by localhost (fly-neu.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GBVPnCbx8FoW; Wed, 11 Jun 2014 15:38:15 +0200 (CEST) Received: from [192.168.178.21] (nightswatch.informatik.hs-augsburg.de [141.82.79.79]) by fly-neu.RZ.HS-Augsburg.DE (Postfix) with ESMTPSA id 667251D6017; Wed, 11 Jun 2014 15:38:14 +0200 (CEST) Message-ID: <53985BC6.6070307@hs-augsburg.de> Date: Wed, 11 Jun 2014 15:38:14 +0200 From: Michael Faath User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: philip.eardley@bt.com, KEN.KO@adtran.com, trevor.burbridge@bt.com, charles.cook2@centurylink.com, lmap@ietf.org References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_RQI2mvFJ_1XWrbV9DmcCi2wKhQ Subject: Re: [lmap] Suppression in 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: Wed, 11 Jun 2014 13:38:26 -0000 I think this describes the different views, inline: On 11.06.2014 14:28, philip.eardley@bt.com wrote: > i don't think that's the difference. > > Example: > tasks 1,2,3 have flag can-be-suppressed > tasks 4,5 have flag do-not-suppress > > General "Suppress" msg: suppresses 1,2,3 (no disagreement) > > "SUppress 2": suppresses 2 only (no disagreement) > > "Suppress 4": > disagreement > Barbara: it suppresses 4 > Trevor: it throws an error > XX: it suppresses 1,2,3,4 (dont think anyone has suggested this, but > someone might argue for it) I agree with Trevor, if a task has the do-not-suppress flag set it should never be suppressed. The only way for suppressing this task should be by sending a new schedule or update the task with the flag not set. > > Also, > "Unsuppress" > I think there's an implicit agreement that there is just a simple > unsuppress msg (which unsupresses any task that is suppressed) > (ie no-one is suggesting also allowing an "Unsuppress 1" msg (that would > unsuppress task 1 but leave other tasks suppressed) > (I think we should only have the simple "Unsuppress" msg) +1 Michael > > ------------------------------------------------------------------------ > *From:* KEN KO [KEN.KO@adtran.com] > *Sent:* 10 June 2014 14:17 > *To:* Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; > charles.cook2@centurylink.com; lmap@ietf.org > *Subject:* RE: [lmap] Suppression in framework > > Sorry if this is a duplicate – I had to reset my membership in the lmap > list. > > > > It seems that we are expressing two different interpretations of this > flag, and we need to converge on one. > > > > Definition “A” > > What I proposed is a flag that **defines** the default suppression > behavior of a task, e.g. in response to a basic suppress message. In > that context, Trevor’s first sentence has no meaning because the flags > themselves define the response to a basic suppress message – that is, > there is nothing to override. The MA interprets the basic suppression > message as “do what the flag says” for each Task. If the flag is > cleared, the task is suppressed by default (using Phil’s do-not-suppress > polarity – I would reverse it, but that’s a minor point). If the flag is > set, the task is not suppressed by default. > > > > Definition “B” > > Trevor and Phil, I think (please correct me if this is wrong) you are > interpreting these flags as identifying exceptions to predefined default > suppression behavior. That is, if the flag is not set the suppression > behavior conforms to a fixed definition, but if the flag is set the Task > is not suppressed. This is a one-way flag – there is no way to use it to > change the default behavior of a Task that is not normally suppressed. > Is this understanding of your interpretation correct? > > > > For what it is worth, I favor “A”. I proposed it to resolve any > ambiguity in the definition of Active vs. Passive as it applies to > default suppression behavior while allowing each operator to define that > behavior on their own terms. “B” doesn’t achieve either of those goals. > > > > Having said all that, I agree with you that communication with the > Controller should never be suppressed. (I’ve seen it listed several > times as an example of a critical task, but no other examples come to > mind that aren’t recoverable via a new Instruction from the Controller.) > So let us define communication with a Controller as always being exempt > from suppression. The MA is configured with the Controller’s address so > it is possible to mark any Task communicating with that address as > “never suppress.” This marking can be done at configuration time > (internally by the MA, no Instruction field required) so addresses don’t > need to be compared at run time. > > > > Ken > > > > *From:*trevor.burbridge@bt.com > [mailto:trevor.burbridge@bt.com] > *Sent:* Tuesday, June 10, 2014 4:27 AM > *To:* philip.eardley@bt.com ; > charles.cook2@centurylink.com ; > KEN KO; lmap@ietf.org > *Subject:* RE: [lmap] Suppression in framework > > > > The last bit is important – when we just send a basic suppress message > (i.e. default suppress everything) then this DOESN’T over-ride the > flags. I wouldn’t be in favour of reversing this when selected > tasks/schedules are listed. I think this would create confusion. > > > > Also I’m in favour of not over-riding to give a bit more accidental > protection to critical tasks, such as communicating with the Controller. > Remember if we do want to over-ride any flags, the controller is free to > either change those flags or remove the task from the schedules. So we > always have the ability to switch off any task. > > > > Trevor. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* 10 June 2014 09:21 > *To:* charles.cook2@centurylink.com > ; KEN.KO@adtran.com > ; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > My take is that the do-not-suppress flag should not be defined in the > Measurement Method. The controller should be able to set it. for some > operators of measurement systems a particular method may be critical, > for some it may be highly optional. > > > > Allowing the optional msg to over-ride the do-not-suppress flag – I > don’t think this is very clean. There are some tasks (communication with > controller) that would need to be marked as ‘really do not suppress, > even if the optional msg says so’. Perhaps also it would mean that the > normal suppress and optional suppress msgs would have to be processed > differently. > > > > > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* 09 June 2014 21:43 > *To:* KEN KO; Eardley,PL,Philip,TUB8 R; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > As soon as I hit send, that thought occurred to me as well, and whether > it would be out of scope. > > Your comment on the MA having to test the configuration against what is > allowed by the Measurement Method may be more trust worthy from the > perspective of the Network owner than the third-party Controller. The > Network owner certainly would not be precluded from designing its MAs to > perform such a test against the Measurement Method. > > I think I am convinced that maybe this is better handled by an agreement > between parties. > > Charles > > On 6/9/2014 2:27 PM, KEN KO wrote: > > But if a third party Controller can be trusted to do the right > thing, then there seems to be little value in a flag in the > Measurement Method that prohibits doing the wrong thing. > > > > Perhaps if that is the case, this is better handled by an agreement > between parties that would be out of scope for lmap? > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 4:16 PM > *To:* KEN KO; philip.eardley@bt.com ; > lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Good point. Or the Controller can do the configuration manipulation > in the creation of the Measurement Task (my preference) so the MA > does not have to. - keep the MA as simple as possible at the > expense of the Controller. > > Charles > > On 6/9/2014 1:35 PM, KEN KO wrote: > > OK, thanks. I read it wrong the first time. I can see some > utility in that, but it does complicate the MA which would have > to test suppression configuration in the Task against what is > allowed by the Measurement Method. > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 3:15 PM > *To:* KEN KO; philip.eardley@bt.com > ; lmap@ietf.org > *Subject:* Re: [lmap] Suppression in framework > > > > Ken, > > I'm not sure I follow your question. If there is a Measurement > Method that has been defined a priori such that the Suppression > behavior defined in the Measurement Method is not to be > over-written, there should be a flag set to indicate that the > Suppression behavior cannot be modified. In other words, if the > defined suppression behavior is permitted to be changed, a flag > in the Measurement Method would be set to > Suppression_Behavior_Modifiable : True. > > A possible use case is one where a Network owner wants to > maintain control of what third-parties do relative to > Suppression behavior on the owner's Network. It is possible > that the owner of a Network could create a registry of > Measurement Methods that are allowable on their Network by third > parties that are using a third-party Controller to measure > portions of the owner's Network. The owner of the Network may > determine that within the set of Measurement Methods, there may > be a subset of Measurement Methods that the Network Owner always > wants to be suppressed when a suppression is sent, and does not > want the third-party Controller to ever override that behavior. > > If the Network owner also owns the Controller, then I can't > think of a good reason to consider this method of dealing with > Suppression. > > Charles > > On 6/9/2014 12:19 PM, KEN KO wrote: > > Charles, > > > > Is there a reason to prevent the do-not-suppress flag from > redefining the default suppression behavior suggested for a > particular Measurement Method in a Registry, yet still allow > it to be overridden by the optional suppression fields? > Seems like that would be a needless limitation on the > information model. > > > > Ken > > > > *From:*Charles Cook [mailto:charles.cook2@centurylink.com] > *Sent:* Monday, June 09, 2014 2:00 PM > *To:* KEN KO; philip.eardley@bt.com > ; lmap@ietf.org > > *Subject:* Re: [lmap] Suppression in framework > > > > Regarding suppression (not communication with the Controller): > My take is that the default suppression behavior can be > coded into the Measurement Method. If there is a > possibility that the default can be overwritten, then an > optional field is added to the Measurement Method. If the > Controller wants to override the default, it must assert the > optional override field when generating the Measurement Task. > > I have not formed an opinion regarding MA communication with > the Controller. > > Charles > > On 6/9/2014 11:05 AM, KEN KO wrote: > > My interpretation of the existing text is that the > option fields already override default behavior. > > > > Given the more general nature of Tasks as you point out, > there may be specific tasks which should simply never be > suppressed, either by default configuration or optional > field. I’m thinking primarily about communication with > the Controller. If we protect that, then suppression of > anything else should be recoverable. And if that is > true, I’m still in favor of the optional fields > overriding the default. > > > > Your thoughts? > > > > *From:*philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] > *Sent:* Monday, June 09, 2014 12:56 PM > *To:* KEN KO; lmap@ietf.org > *Subject:* RE: Suppression in framework > > > > Over-ride might make it a bit too easy to accidentally > suppress a really crucial Task such as reporting to the > collector or communication with the controller (since > tasks are now general and not just measurement tasks). > Or deliberately by an attacker. > > > > If the controller wants to suppress a task with the > do-not-suppress flag set, then it would either re-does > the task configuration or it updates the schedule > > > > *From:*KEN KO [mailto:KEN.KO@adtran.com] > *Sent:* 09 June 2014 17:49 > *To:* Eardley,PL,Philip,TUB8 R; lmap@ietf.org > > *Subject:* RE: Suppression in framework > > > > I would think that information in the optional Suppress > fields would override the default behavior flag. That > is, if the do-not-suppress flag was set for a given > task, yet a Suppression message specifically listed that > same task (or schedule containing the Task), the task > would then be suppressed and no error would be thrown. > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* Monday, June 09, 2014 12:43 PM > *To:* lmap@ietf.org > *Subject:* [lmap] Suppression in framework > > > > So we have agreed to modify suppression so the default > behaviour is that tasks have a Boolean flag which > indicates whether or not a Suppress message will > suppress them. > > Question: what do we want the impact of the flag to be > when we have the more complex, optional Suppress > message? (it lists specific Tasks or Schedules for > suppression.) > > http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15 > > > > > Treating the Boolean flag as meaning “do-not-suppress > this Measurement Task”, my proposal is to basically keep > the current text unaltered: > > > > > << Optionally the Suppression information may > > include: > > > > o a set of Measurement Tasks to suppress; the others > are not > > suppressed. For example, this could be useful if > a particular > > Measurement Task is overloading a Measurement Peer. > > > > o a set of Measurement Schedules to suppress; the > others are not > > suppressed. For example, suppose the measurement > system has > > defined two Schedules, one with the most critical > Measurement > > Tasks and the other with less critical ones that > create a lot of > > Active Measurement Traffic, then it may only want > to suppress the > > second. > > > > o a start time, at which suppression begins > > > > o an end time, at which suppression ends > > > > o a demand that the MA ends its on-going Active > Measurement Task(s) > > (and deletes the associated partial Measurement > Result(s)). > > >> > > > > In other words, if the Controller says “Suppress Task > #213” then the MA checks the do-not-suppress flag for > Task #213 and either throws an error or doesn’t start > this Task. Similarly, if the Controller says “Suppress > Schedule #49”, then the MA checks the do-not-suppress > flag for Tasks in this schedule and either throws an > error or doesn’t start any new Tasks in this schedule. > > > > I’ll tweak the text to say this (as well as removing the > refs to Active). > > I’ll also make clear that the Controller sets the > do-not-suppress flag for a Task (it isn’t something that > the MA decides about). > > > > Thanks > > phil > > > > > _______________________________________________ > > 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 [Call: 303.992.8952] Fax: 925.281.0662 [Call: 925.281.0662] > > charles.cook2@centurylink.com > > > > -- > > > > Charles Cook > > Principal Architect > > Network > > 5325 Zuni Street; Suite 224 > > Denver, CO 80221 > > Tel: 303.992.8952 [Call: 303.992.8952] Fax: 925.281.0662 [Call: 925.281.0662] > > charles.cook2@centurylink.com > > > > -- > > > > Charles Cook > > Principal Architect > > Network > > 5325 Zuni Street; Suite 224 > > Denver, CO 80221 > > Tel: 303.992.8952 [Call: 303.992.8952] Fax: 925.281.0662 [Call: 925.281.0662] > > charles.cook2@centurylink.com > > > > -- > > > > Charles Cook > > Principal Architect > > Network > > 5325 Zuni Street; Suite 224 > > Denver, CO 80221 > > Tel: 303.992.8952 [Call: 303.992.8952] Fax: 925.281.0662 [Call: 925.281.0662] > > charles.cook2@centurylink.com > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > From nobody Wed Jun 11 07:41: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 930251A0141 for ; Wed, 11 Jun 2014 07:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 D4ZUag9OsaET for ; Wed, 11 Jun 2014 07:41:06 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4E21A0127 for ; Wed, 11 Jun 2014 07:41:06 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO p01c12o148.mxlogic.net) by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 28a68935.2b5f917c7940.31389.00-593.90155.p01c12o148.mxlogic.net (envelope-from ); Wed, 11 Jun 2014 08:41:06 -0600 (MDT) X-MXL-Hash: 53986a8272880dca-a26b7e1cc8179e50abc693d3d5e1e0bf6e3371b6 Received: from unknown [76.164.174.82] by p01c12o148.mxlogic.net(mxl_mta-8.0.0-1) with SMTP id 97a68935.0.30989.00-046.89358.p01c12o148.mxlogic.net (envelope-from ); Wed, 11 Jun 2014 08:41:04 -0600 (MDT) X-MXL-Hash: 53986a80752a39d9-da8801fa157feb31ddf2476f8107f8cfe99d490c Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 09:40:45 -0500 From: KEN KO To: Michael Faath , "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hCAAVeqiIAAaM8AgABQ7JA= Date: Wed, 11 Jun 2014 14:40:44 +0000 Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , <53985BC6.6070307@hs-augsburg.de> In-Reply-To: <53985BC6.6070307@hs-augsburg.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Mo/c6gqe c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=eY56GQPitMMA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=eQtCghFvH8AA:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=1-XVwAU98oEyALuDxI4A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061113); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2RRVWrmiFA3XVsnFyjx1mku1rjM Subject: Re: [lmap] Suppression in 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: Wed, 11 Jun 2014 14:41:08 -0000 Phil, thank you for correcting my understanding of Trevor's proposed behavi= or. I'm going to summarize my understanding of each proposed definition for= the flag, along with descriptive names for each and for the values they ca= n take. Please correct me if I get anything wrong. Then, I'll attempt to ju= stify my preference. *** Definitions *** "Default-Behavior" - The values are suppress-by-default and do-not-suppress= -by-default. Either polarity may be over-ridden by an optional suppression = list. "Disable-Suppress" - The values are can-be-suppressed and do-not-suppress. = A task with the can-be-suppressed flag is suppressed by default and the beh= avior may be over-ridden by an optional list. A task with the do-not-suppre= ss flag may never be suppressed. *** Justification *** Here is a scenario: An operator schedules periodic tests that include throughput (large volume = of active measurement traffic), TWAMP (small volume of active measurement t= raffic), and a byte counter (no active measurement traffic). The desired re= sponse to a basic suppression message is: Throughput suppressed TWAMP not suppressed Byte counter not suppressed This default suppression behavior is configured similarly with either flag. The operator would also like to be able to suppress both throughput and TWA= MP if necessary. With Default-Behavior, this is done via a Suppress message with an optional= list itemizing throughput and TWAMP. Suppression is terminated normally us= ing the Unsuppress message.=20 With Disable-Suppress, this requires reconfiguration of the Schedules, or r= econfiguration of the Task flags followed by a Suppress message, in every M= A. It then requires a second reconfiguration of every MA to restore the ori= ginal behavior. The only rationale I have seen for Disable-Suppress is to protect communica= tion with the Controller, and multiple messages on this thread have indicat= ed that there are better ways to accomplish that protection. To be very clear - I strongly support Default-Behavior and I think Disable-= Suppress needlessly limits the usefulness of the flag. Thanks, Ken From nobody Wed Jun 11 08:34: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 4224C1A0157 for ; Wed, 11 Jun 2014 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 2s1okBUUuNJ8 for ; Wed, 11 Jun 2014 08:34:48 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4161A0150 for ; Wed, 11 Jun 2014 08:34:48 -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 81778935.2b3f6de02940.3332925.00-2416.9331278.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 11 Jun 2014 15:34:48 +0000 (UTC) X-MXL-Hash: 539877187efee0cb-38be6523b82ad9c6f72934b9515dd703ae0376f9 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 0b678935.0.3331449.00-2241.9327189.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 11 Jun 2014 15:33:06 +0000 (UTC) X-MXL-Hash: 539876b2721cc24c-07fad7dab48e7b9d3263ff8155b24e835cf7bc07 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 s5BFX4nV031587; Wed, 11 Jun 2014 11:33:04 -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 s5BFWxMK031519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 11:33:01 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (GAALPA1MSGHUB9E.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 11 Jun 2014 15:32:43 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 11:32:44 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: how would MA-Controller channel be impacted by suppression? Thread-Index: Ac+Eu28IWvKIWLxYQX2oXvR0ECMYXAAtWHj4AAEdjVA= Date: Wed, 11 Jun 2014 15:32:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE8511@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE7EF7@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.144.17] 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=OMyQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=2NOt5wbEoBEA:10 a=ofMgfj31e3cA:10 a=zbdaSqSUbfwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=IRATx0kIrMMJdzhtZ18A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/V5xgOuFy0s52YtjBtzD_Jxuqs6M Subject: Re: [lmap] how would MA-Controller channel be impacted by suppression? 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, 11 Jun 2014 15:34:50 -0000 > i think you're reading this right - think the gap is that the information= model i- > d needs an update they should all be tasks with schedules incidentally, a= lso > suggestion is (will be) to merge config and bootstrap into single object = (since > they affect the same info) I'll have to wait to see the changes. If one of the changes is to remove ma= -channel-timing from ma-channel-obj and place it elsewhere, so that when to= establish a channel connection is associated with a ma-schedule-obj and n= ot a ma-channel-obj, then I need to see this change in order to grasp (and = agree with) it. I'm also concerned with turning configuration and receipt o= f Instruction into ma-task entries. (If that's what I'm understanding? But = I need to see what you're really saying.) Currently, there is reasonable co= rrelation between ma-task and Measurement Task. I can even see the status a= nd capability info as Measurement Task. But I can't see configuration and I= nstruction receipt as Measurement Tasks. If that happens, then we need to s= pecifically say that Measurement Tasks are a subset of ma-task entries, and= somehow know which ma-task entries represent Measurement Tasks. Because Su= ppression applies to Measurement Tasks. It can only apply to a ma-task entr= y if that ma-task entry is representing a Measurement Task. Suppression mus= t not be modeled in a way that could cause it to apply to all possible acti= vities (tasks) performed by a MA. Just the Measurement Tasks. Anyway, I'll wait to see the proposed changes before discussing this furthe= r. It's hard to discuss in the absence of something concrete to point to (i= .e., information-model-01). Barbara > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H > [bs7652@att.com] > Sent: 10 June 2014 15:51 > To: lmap@ietf.org > Subject: [lmap] how would MA-Controller channel be impacted by > suppression? >=20 > Something that's been nagging at my brain is the idea that the > communication between MA and Controller is a "task" (this been said durin= g > the suppression flag discussions) that could potentially be suppressed. >=20 > I thought that establishment of this communication was defined by a ma- > channel-obj that has its own timing info as to when to establish the > connection. And I didn't think it was possible to include a ma-channel-ob= j in > the suppression list. >=20 > Going up the chain, to objects that point to ma-channel-obj, I don't see = how > the following could be impacted by suppression: > ma-preconfig-obj (which sets the ma-ma-to-controller-channel and the ma- > instruction-channel) [BTW is there something that requires the ma-channel= - > target of these 2 ma-channel-obj parameters to be the same, because both > of these should be MA-Controller communication, just potentially with > different timing? Currently it looks like there could be a separate "Cont= roller" > communicated with for ma-to-controller instruction purposes but we said > only one Controller for a MA? Do we need 2?] ma-config-obj (which can als= o > set the ma-instruction-channel) ma-instruction-obj (which presumably gets > updated or overwritten per the ma-instruction-channel's connectivity and > timing info) ma-status-obj (which uses the ma-ma-to-controller-channel?) >=20 > It reads as if ma-log-obj (which relates to the logging of various info) = can be > impacted by suppression, because logs are described as scheduled tasks. B= ut > the lack of pointers between ma-log-obj and any other objects makes this > very unclear. >=20 > >From what I can see, only Measurement Tasks (ma-task-obj) and Schedules > can be directly impacted by Suppression, which will impact associated > Reports and logs. > The MA will continue to communicate with the Controller at the Channel- > specified times and allow for updating of the Instruction and providing s= tatus. >=20 > Or am I reading this wrong? > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Jun 11 09:01: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 2E2791B27A8 for ; Wed, 11 Jun 2014 09:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 rZIi_zV2la1g for ; Wed, 11 Jun 2014 09:01:53 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B211A063B for ; Wed, 11 Jun 2014 09:01:52 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 07d78935.2ad137adf940.3757623.00-2496.10501360.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 11 Jun 2014 16:01:52 +0000 (UTC) X-MXL-Hash: 53987d704a18f992-191e4f5b5b6cbedaeeb12c966acb47e3e2338993 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 2fc78935.0.3755154.00-2015.10494416.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 11 Jun 2014 15:59:47 +0000 (UTC) X-MXL-Hash: 53987cf32d71e4c4-1404649e973ad4a0e92c43a1b8c3e5664839a16d 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 s5BFxipD000497; Wed, 11 Jun 2014 11:59:45 -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 s5BFxXjI032332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 11:59:36 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Wed, 11 Jun 2014 15:59:10 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 11:59:10 -0400 From: "STARK, BARBARA H" To: KEN KO , Michael Faath , "philip.eardley@bt.com" , "trevor.burbridge@bt.com" , "charles.cook2@centurylink.com" , "lmap@ietf.org" Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hCAAVeqiIAAWAwAgAARdgCAADPHcA== Date: Wed, 11 Jun 2014 15:59:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE855D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , <53985BC6.6070307@hs-augsburg.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.144.17] 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=BqQqN/r5 c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=eY56GQPitMMA:10 a=ofMgfj31e3cA:10 a=zbdaSqSUbfwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8 ] X-AnalysisOut: [a=ixc4uOFi4qBCJo864F0A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=W1qU_X6G3J8A:10 a=Pwbduc0PQ3sA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/U6dJ3iXCLpZYPQZXVZ7TfEtlxX8 Subject: Re: [lmap] Suppression in 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: Wed, 11 Jun 2014 16:01:55 -0000 +1 And one additional justification: Actually, the first value of the Disable-= Suppress option is can-be-suppressed-AND-is suppressed-by-default. This is = not the opposite of do-not-suppress. Flag (Boolean) values need to be oppos= ites, or else they run into trouble. The flag's meaning in the proposed Dis= able-Suppress option is being overloaded by having non-opposing information= expressed through it. To fix this, it would either be necessary to have 2 = flags, or to use a multi-value parameter.=20 Using 2 flags: Disable-Suppress flag: suppression-allowed and suppression-not-allowed Default-Behavior flag: suppress-by-default and do-not-suppress-by-default If no optional list, then all Measurement Tasks with suppression-allowed AN= D suppress-by-default are suppressed. No others are suppressed. If optional list, then all listed (directly or indirectly via a schedule) M= easurement Tasks with suppression-allowed are suppressed. No others are sup= pressed. Using multi-value parameter: Suppress-Behavior: allowed values are suppression-allowed-AND-suppress-by-d= efault; suppression-allowed-AND-do-not-suppress-by-default; suppression-not= -allowed I would have no problem with either of the above 2 possible approaches that= do not overload the meaning of a Boolean flag by using non-opposite meanin= gs of the 2 values. I have a problem with any approach that does overload t= he meaning of a Boolean flag. Barbara > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO > Sent: Wednesday, June 11, 2014 10:41 AM > To: Michael Faath; philip.eardley@bt.com; trevor.burbridge@bt.com; > charles.cook2@centurylink.com; lmap@ietf.org > Subject: Re: [lmap] Suppression in framework >=20 > Phil, thank you for correcting my understanding of Trevor's proposed > behavior. I'm going to summarize my understanding of each proposed > definition for the flag, along with descriptive names for each and for th= e > values they can take. Please correct me if I get anything wrong. Then, I'= ll > attempt to justify my preference. >=20 > *** Definitions *** >=20 > "Default-Behavior" - The values are suppress-by-default and do-not- > suppress-by-default. Either polarity may be over-ridden by an optional > suppression list. >=20 > "Disable-Suppress" - The values are can-be-suppressed and do-not- > suppress. A task with the can-be-suppressed flag is suppressed by default > and the behavior may be over-ridden by an optional list. A task with the = do- > not-suppress flag may never be suppressed. >=20 > *** Justification *** >=20 > Here is a scenario: >=20 > An operator schedules periodic tests that include throughput (large volum= e > of active measurement traffic), TWAMP (small volume of active > measurement traffic), and a byte counter (no active measurement traffic). > The desired response to a basic suppression message is: > Throughput suppressed > TWAMP not suppressed > Byte counter not suppressed > This default suppression behavior is configured similarly with either fla= g. >=20 > The operator would also like to be able to suppress both throughput and > TWAMP if necessary. >=20 > With Default-Behavior, this is done via a Suppress message with an option= al > list itemizing throughput and TWAMP. Suppression is terminated normally > using the Unsuppress message. >=20 > With Disable-Suppress, this requires reconfiguration of the Schedules, or > reconfiguration of the Task flags followed by a Suppress message, in ever= y > MA. It then requires a second reconfiguration of every MA to restore the > original behavior. >=20 > The only rationale I have seen for Disable-Suppress is to protect > communication with the Controller, and multiple messages on this thread > have indicated that there are better ways to accomplish that protection. >=20 > To be very clear - I strongly support Default-Behavior and I think Disabl= e- > Suppress needlessly limits the usefulness of the flag. >=20 > Thanks, > Ken >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Wed Jun 11 18:44:28 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 4547F1B295E for ; Wed, 11 Jun 2014 18:44:26 -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 DCxT57rbth7J for ; Wed, 11 Jun 2014 18:44:24 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CC51B295C for ; Wed, 11 Jun 2014 18:44:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hy10so130573vcb.31 for ; Wed, 11 Jun 2014 18:44:23 -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 :content-type; bh=dgAVYO7F79EID95jAg0D1KFsqozbBZ348fySd+AmgHY=; b=uO13hos8k0hM3n+Eis8RwzEhH5R3xoaK8l4BGn7FQ7ZjskAuKWl2izZiAIA2qL02Ec gGAXnYgDtk8qTp46bFOs+EBl7OhvWmHtuIP6ereHy1DeOBXx/82J1Z5kFTq+9oVxr2Pq 88MvPH6PAjVyGpvhHK6PoEH/hpSlbETTdGQXlzCZj+UikxFQPW9Caws1MPgbSXucRxjP IN6PB2VG+EcmNy/6Wva9mzYCUfbGLWQ7VmLZueadJCQ1Tk/DiVSqA1Eo6I/7VMTZ/5C3 Tu5LUZfqoMITkAXZ0D9P40Mo0ohliZLOzVrcjD3kHjk/pDucszbZisyQla0I3dqHBeON hUoA== MIME-Version: 1.0 X-Received: by 10.220.253.132 with SMTP id na4mr5943308vcb.39.1402537463381; Wed, 11 Jun 2014 18:44:23 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Wed, 11 Jun 2014 18:44:23 -0700 (PDT) In-Reply-To: <53976589.5080809@centurylink.com> References: <2D09D61DDFA73D4C884805CC7865E61130DE6CDB@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E61130DE7EA1@GAALPA1MSGUSRBF.ITServices.sbc.com> <53976589.5080809@centurylink.com> Date: Wed, 11 Jun 2014 18:44:23 -0700 Message-ID: From: Greg Mirsky To: "philip.eardley@bt.com" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary=001a1133ddf84a03bd04fb99b32a Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/msT4r2IKJNrcYvVqKwjoJ5c_gPg Subject: Re: [lmap] Measurement Methods and Tasks 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, 12 Jun 2014 01:44:26 -0000 --001a1133ddf84a03bd04fb99b32a Content-Type: text/plain; charset=UTF-8 Hi Phil, not sure whether in our discussion of Active/Passive Measurement methods in LMAP Framework we've looked at how proposed changes get reflected in Figure 1 in Section 2. If we have agreed that LMAP Framework should be transparent whether Measurement Method/Task is Active or Passive, then I'd suggest to remove 'Active' from 'Active Measurement Traffic'. I think that 'Measurement Traffic' will correctly characterize data flow between MA and MP. Regards, Greg On Tue, Jun 10, 2014 at 1:07 PM, Charles Cook wrote: > +1 > On 6/10/2014 9:20 AM, KEN KO wrote: > >> I would prefer: > >> Measurement Task: The action performed by a particular Measurement > >> Agent that consists of the single operation of a Measurement Method > >> role at a particular time and with all of the role's Input Parameters > set > >> to specific values. > > +1 to the above. > > > >> Alternately, we could go with Charles' approach and define > >> "Measurement Method" as "the role of a participating point in a > >> holistic measurement technique". Then the proposed definition > >> would be accurate. Personally, I think this may add to confusion, > >> because so many people already consider "Measurement Method" > >> to be the holistic technique. > > I agree that this terminology would be confusing. I prefer the first > alternative above. > > > > Ken > > > > _______________________________________________ > > 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 > --001a1133ddf84a03bd04fb99b32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
not sure whether in our discus= sion of Active/Passive Measurement methods in LMAP Framework we've look= ed at how proposed changes get reflected in Figure 1 in Section 2. If we ha= ve agreed that LMAP Framework should be transparent whether Measurement Met= hod/Task is Active or Passive, then I'd suggest to remove 'Active&#= 39; from 'Active Measurement Traffic'. I think that 'Measuremen= t Traffic' will correctly characterize data flow between MA and MP.

Regards,
Greg


On Tue, Jun 10, 2014 at 1:07 PM, Charles Cook <charles.cook2@centurylink.com> wrote:
+1
On 6/10/2014 9:20 AM, KEN KO wrote:=
>> I would prefer:
>> Measurement Task: The action performed by a particular Measurement=
>> Agent that consists of the single operation of a Measurement Metho= d
>> role at a particular time and with all of the role's Input Par= ameters set
>> =C2=A0to specific values.
> +1 to the above.
>
>> Alternately, we could go with Charles' approach and define
>> "Measurement Method" as "the role of a participatin= g point in a
>> holistic measurement technique". Then the proposed definition=
>> would be accurate. Personally, I think this may add to confusion,<= br> >> because so many people already consider "Measurement Method&q= uot;
>> to be the holistic technique.
> I agree that this terminology would be confusing. I prefer the first a= lternative above.
>
> Ken
>
> _______________________________________________
> 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 =C2=A080221
Tel: =C2=A0303.992.8952= =C2=A0Fax: =C2=A09= 25.281.0662
charles.cook2@centurylink.= com

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

--001a1133ddf84a03bd04fb99b32a-- From nobody Thu Jun 12 00:51: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 99BC81A039B for ; Thu, 12 Jun 2014 00:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, 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 7Izvnl8Mc081 for ; Thu, 12 Jun 2014 00:51:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0C41A0641 for ; Thu, 12 Jun 2014 00:51:53 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Jun 2014 08:52:10 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.235]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 12 Jun 2014 08:51:51 +0100 From: To: , , , , , Date: Thu, 12 Jun 2014 08:51:50 +0100 Thread-Topic: [lmap] Suppression in framework Thread-Index: Ac+D/0pvPRmBiaL7SQu6q13mjwJSWwAAt7dAAAA4c7AAADknwAAMozeAAAn4pYD//8UxgIAAT1mw///B64CAAFM74P//tCGAgADDFYCAAAGRgIAAEwpggAAV4hCAAVeqiIAAWAwAgAARdgCAADPHcP//V5jg Message-ID: References: <5395F609.8020003@centurylink.com> <5396079F.9070106@centurylink.com> <5396161B.3050509@centurylink.com> <53961C47.7040708@centurylink.com> , <53985BC6.6070307@hs-augsburg.de> <2D09D61DDFA73D4C884805CC7865E61130DE855D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DE855D@GAALPA1MSGUSRBF.ITServices.sbc.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/y60PdWLgJnHHGI371GKwKD3JtVY Subject: Re: [lmap] Suppression in 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, 12 Jun 2014 07:51:56 -0000 OK - seems like I've lost this vote. I will correct the information model to: - add a "suppress-by-default" flag to the task configuration If this flag is set then the general suppress message will default to all t= asks with this flag set. If tasks or schedules are listed then those listed= will be suppressed regardless of this flag. 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: STARK, BARBARA H [mailto:bs7652@att.com] >Sent: 11 June 2014 16:59 >To: KEN KO; Michael Faath; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TU= B8 R; >charles.cook2@centurylink.com; lmap@ietf.org >Subject: RE: [lmap] Suppression in framework > >+1 >And one additional justification: Actually, the first value of the Disable= -Suppress >option is can-be-suppressed-AND-is suppressed-by-default. This is not the >opposite of do-not-suppress. Flag (Boolean) values need to be opposites, o= r else >they run into trouble. The flag's meaning in the proposed Disable-Suppress= option >is being overloaded by having non-opposing information expressed through i= t. To >fix this, it would either be necessary to have 2 flags, or to use a multi-= value >parameter. > >Using 2 flags: >Disable-Suppress flag: suppression-allowed and suppression-not-allowed Def= ault- >Behavior flag: suppress-by-default and do-not-suppress-by-default If no op= tional >list, then all Measurement Tasks with suppression-allowed AND suppress-by- >default are suppressed. No others are suppressed. >If optional list, then all listed (directly or indirectly via a schedule) = Measurement >Tasks with suppression-allowed are suppressed. No others are suppressed. > >Using multi-value parameter: >Suppress-Behavior: allowed values are suppression-allowed-AND-suppress-by- >default; suppression-allowed-AND-do-not-suppress-by-default; suppression-n= ot- >allowed > >I would have no problem with either of the above 2 possible approaches tha= t do >not overload the meaning of a Boolean flag by using non-opposite meanings = of >the 2 values. I have a problem with any approach that does overload the me= aning >of a Boolean flag. >Barbara > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO >> Sent: Wednesday, June 11, 2014 10:41 AM >> To: Michael Faath; philip.eardley@bt.com; trevor.burbridge@bt.com; >> charles.cook2@centurylink.com; lmap@ietf.org >> Subject: Re: [lmap] Suppression in framework >> >> Phil, thank you for correcting my understanding of Trevor's proposed >> behavior. I'm going to summarize my understanding of each proposed >> definition for the flag, along with descriptive names for each and for >> the values they can take. Please correct me if I get anything wrong. >> Then, I'll attempt to justify my preference. >> >> *** Definitions *** >> >> "Default-Behavior" - The values are suppress-by-default and do-not- >> suppress-by-default. Either polarity may be over-ridden by an optional >> suppression list. >> >> "Disable-Suppress" - The values are can-be-suppressed and do-not- >> suppress. A task with the can-be-suppressed flag is suppressed by >> default and the behavior may be over-ridden by an optional list. A >> task with the do- not-suppress flag may never be suppressed. >> >> *** Justification *** >> >> Here is a scenario: >> >> An operator schedules periodic tests that include throughput (large >> volume of active measurement traffic), TWAMP (small volume of active >> measurement traffic), and a byte counter (no active measurement traffic)= . >> The desired response to a basic suppression message is: >> Throughput suppressed >> TWAMP not suppressed >> Byte counter not suppressed >> This default suppression behavior is configured similarly with either fl= ag. >> >> The operator would also like to be able to suppress both throughput >> and TWAMP if necessary. >> >> With Default-Behavior, this is done via a Suppress message with an >> optional list itemizing throughput and TWAMP. Suppression is >> terminated normally using the Unsuppress message. >> >> With Disable-Suppress, this requires reconfiguration of the Schedules, >> or reconfiguration of the Task flags followed by a Suppress message, >> in every MA. It then requires a second reconfiguration of every MA to >> restore the original behavior. >> >> The only rationale I have seen for Disable-Suppress is to protect >> communication with the Controller, and multiple messages on this >> thread have indicated that there are better ways to accomplish that prot= ection. >> >> To be very clear - I strongly support Default-Behavior and I think >> Disable- Suppress needlessly limits the usefulness of the flag. >> >> Thanks, >> Ken >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap From nobody Fri Jun 13 05:34: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 A5E691A04CA; Fri, 13 Jun 2014 05:33:55 -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 OzObMmQ8A5zA; Fri, 13 Jun 2014 05:33:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A40F1B284E; Fri, 13 Jun 2014 05:33:52 -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.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613123352.31642.70069.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 05:33:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/zr441JKrz2B3AwMLbjFMCH0C1Sg Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:33:55 -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-06.txt Pages : 54 Date : 2014-06-13 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 13 05:39:14 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 B6B731B2849 for ; Fri, 13 Jun 2014 05:39:11 -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 7Ju6_wKrpFvJ for ; Fri, 13 Jun 2014 05:39:08 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7AF1A04CA for ; Fri, 13 Jun 2014 05:39:07 -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.181.6; Fri, 13 Jun 2014 13:39:23 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 13 Jun 2014 13:39:02 +0100 From: To: Date: Fri, 13 Jun 2014 13:38:59 +0100 Thread-Topic: new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1Ggvw== 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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3FD4EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9VubWCESQ8aYH_CRJrVv5YRXKd8 Subject: [lmap] new version of 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: Fri, 13 Jun 2014 12:39:11 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3FD4EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt Barbara, Greg, Ken and others who've made suggestions - Please could you do= a quick check to make sure we got your points properly Thanks Phil --12.6. From -05 to -06 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. I now see a glitch! The final 2 bullets should be replaced by:- o removed Configuration Protocol - Configuration is part of the Instruc= tion and so uses the Control Protocol --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3FD4EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just uploaded a new ver= sion

http://www.ietf.org/id/draft-ietf-lmap-frame= work-06.txt

 

Barbara, Greg, Ken and others who’ve made suggestions -= Please could you do a quick check to make sure we got your points properly=

 

T= hanks

Phil

 

--12.6.  From -05 to -06=

 

   o  clarified terminlogy around Me= asurement Methods and Tasks.  Since

      within a Method there may= be several different roles (requester

      and responder, for instance= )

 

   o  Suppression: t= here is now the concept of a flag (boolean) which

      indicates whethe= r a Task is by default gets suppressed or not.

      The optional suppre= ssion message (with list of specific tasks

      /schedules to suppress)= over-rides this flag.

 

   o=   The previous bullet also means there is no need to make a=

      d= istinction between active and passive Measurement Tasks, so this=

      d= istinction is removed.

 

I now see a gl= itch! The final 2 bullets should be replaced by:-

 

   o  removed Configuration Protocol – Co= nfiguration is part of the Instruction and so uses the Control Protocol

 

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4CA3FD4EMV67UKRDdoma_-- From nobody Fri Jun 13 10:33: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 9DD5D1A0645 for ; Fri, 13 Jun 2014 10:33:29 -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 YsnZZMnrhsec for ; Fri, 13 Jun 2014 10:33:28 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82D11B27BC for ; Fri, 13 Jun 2014 10:33:27 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id oy12so1784370veb.9 for ; Fri, 13 Jun 2014 10:33:27 -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=j5nrwjC0I1OEsaXYsLXvXRSY1qhlqnGVj5uEy7FEEt8=; b=tyrzrZqLZgjXaYclqFEEDvQ2tuBT5VAKnN736FkzWov6RlwfdAgGwlUgvQYCwcLG1A oGTg/CcffNO5Rnbw6bETsDWfGoU61fyC4WUi7CtkDBQNO/pov87HuERGHZmdZrS49t/I g8Dy88/Fh2WuR6qYEhYO93hccXYJlzk0cy79iEzO1TpbEqMIqWJ/Zgf2V5daoWwyUjhR FWSbfhpS3qggBt1KcUR8Jnk/H/1F227XZuPTKNyWeY8fOPrtHZhMdxMasY9MI+/iZyW6 uuZNt1TZ6f5E/uj/gw5U120DKtYr2svDt+mB6K6hm6vvH3608sffvcedBNVR/0zWobax QGHA== MIME-Version: 1.0 X-Received: by 10.52.110.105 with SMTP id hz9mr2294979vdb.9.1402680806854; Fri, 13 Jun 2014 10:33:26 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Fri, 13 Jun 2014 10:33:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Jun 2014 10:33:26 -0700 Message-ID: From: Greg Mirsky To: "philip.eardley@bt.com" Content-Type: multipart/alternative; boundary=bcaec547c08d39d72704fbbb13ee Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/NGUsIcNt9X1z66lG0H3kzJ_DmvI Cc: "lmap@ietf.org" Subject: Re: [lmap] new version of 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: Fri, 13 Jun 2014 17:33:29 -0000 --bcaec547c08d39d72704fbbb13ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Phil, many thanks for kind consideration my comments and thoroughly addressing them. Minor point to definition of the control protocol in Section 3 Terminology it doesn't list MA configuration as one of functions performed through the Control protocol though later on page 13 we state (added in -06) "Finally, it allows the Controller to update the MA's configuration". Just in case there will ever be -07 version. Regards, Greg On Fri, Jun 13, 2014 at 5:38 AM, wrote: > I just uploaded a new version > > http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt > > > > Barbara, Greg, Ken and others who=E2=80=99ve made suggestions - Please co= uld you > do a quick check to make sure we got your points properly > > > > Thanks > > Phil > > > > --12.6. From -05 to -06 > > > > o clarified terminlogy around Measurement Methods and Tasks. Since > > within a Method there may be several different roles (requester > > and responder, for instance) > > > > o Suppression: there is now the concept of a flag (boolean) which > > indicates whether a Task is by default gets suppressed or not. > > The optional suppression message (with list of specific tasks > > /schedules to suppress) over-rides this flag. > > > > o The previous bullet also means there is no need to make a > > distinction between active and passive Measurement Tasks, so this > > distinction is removed. > > > > I now see a glitch! The final 2 bullets should be replaced by:- > > > > o removed Configuration Protocol =E2=80=93 Configuration is part of t= he > Instruction and so uses the Control Protocol > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > > --bcaec547c08d39d72704fbbb13ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phil,
many thanks for kind cons= ideration my comments and thoroughly addressing them. Minor point to defini= tion of the control protocol in Section 3 Terminology it doesn't list M= A configuration as one of functions performed through the Control protocol = though later on page 13 we state (added in -06) "Fina= lly, it allows the Controller to update the MA'= s configuration". Just in case there will ever be -07 version.

Regards,
Greg


On Fri, Jun 13, 2014 at 5:38 AM, <philip.eardley@bt.com&= gt; wrote:

I just uploaded a new version=

http://www.ietf.org/id/draft-i= etf-lmap-framework-06.txt

=C2=A0

Barbara, Greg, Ken and others who=E2=80=99ve made= suggestions - Please could you do a quick check to make sure we got your p= oints properly

=C2=A0

Thanks

Phil

=C2=A0

--12.6.=C2=A0 From -05 to -06

=C2=A0

=C2=A0=C2=A0 o=C2=A0 clarified terminlogy around Measureme= nt Methods and Tasks.=C2=A0 Since

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 within a Method there may be several differe= nt roles (requester

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and responder, for instance= )

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Suppression: there is now the concept= of a flag (boolean) which

<= span style=3D"font-size:10.0pt;font-family:"Courier New"">=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 indicates whether a Task is by default gets suppre= ssed or not.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The optional suppression me= ssage (with list of specific tasks

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /schedules to suppress) over-rides this fla= g.

=C2=A0

=C2=A0=C2= =A0 o=C2=A0 The previous bullet also means there is no need to make a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 distinction between active = and passive Measurement Tasks, so this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 distinction is removed.

=C2=A0

I now see = a glitch! The final 2 bullets should be replaced by:-<= /p>

=C2=A0

=C2=A0=C2= =A0 o=C2=A0 removed Configuration Protocol =E2=80=93 Configuration is part = of the Instruction and so uses the Control Protocol

=C2=A0


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


--bcaec547c08d39d72704fbbb13ee-- From nobody Fri Jun 13 19:58: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 8E3581B2874 for ; Fri, 13 Jun 2014 19:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.672 X-Spam-Level: ** X-Spam-Status: No, score=2.672 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 BckP40u7LPnT for ; Fri, 13 Jun 2014 19:57:58 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 89F801B282C for ; Fri, 13 Jun 2014 19:57:56 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee1539bba08510-5b510; Sat, 14 Jun 2014 10:57:13 +0800 (CST) X-RM-TRANSID: 2ee1539bba08510-5b510 Received: from [10.189.109.213] (unknown[117.136.38.169]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2539bba019ec-9bc70; Sat, 14 Jun 2014 10:57:13 +0800 (CST) X-RM-TRANSID: 2ee2539bba019ec-9bc70 Date: Sat, 14 Jun 2014 10:52:43 +0800 Message-ID: From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "philip.eardley" , lmap Content-Type: multipart/alternative; boundary="----OW90LQDOSB501TMNY019UVWY61UEGQ" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7evqZcv9WJr2Qpi5vc2dfxCEvpA Subject: [lmap] =?utf-8?b?5Zue5aSN77yaIG5ldyB2ZXJzaW9uIG9mIGZyYW1ld29yaw==?= 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: Sat, 14 Jun 2014 02:58:00 -0000 ------OW90LQDOSB501TMNY019UVWY61UEGQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgUGhpbCwKClRoZXJlIGlzIGEgc21hbGwgaXNzdWUgd2l0aCA1LjIuMi4xLCB3aGVyZSB0aGUg c3RhcnQgdGltZSwgZW5kIHRpbWUgYW5kIG9uIGdvaW5nIHN1cHByZXNzIGluIGEgc3VwcHJlc3Np b24gbWVzc2FnZSBhcmUgc3RhdGVkIGFzIG9wdGlvbmFsIGluIHRoZSB0ZXh0LCBidXQgYXJlIG5v dCBtYXJrZWQgYXMgb3B0aW9uYWwgaW4gdGhlIGZpZ3VyZSB3aXRoIGJyYWNrZXRzLgoKTGluZ2xp CgotLS0tLS0tLS0tCuWPkeiHquaIkeeahHZpdm/mmbrog73miYvmnLoKCnBoaWxpcC5lYXJkbGV5 QGJ0LmNvbee8luWGme+8mgoK ------OW90LQDOSB501TMNY019UVWY61UEGQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 SGkgUGhpbCw8YnI+PGJyPlRoZXJlIGlzIGEgc21hbGwgaXNzdWUgd2l0aCA1LjIuMi4xLCB3aGVy ZSB0aGUgc3RhcnQgdGltZSwgZW5kIHRpbWUgYW5kIG9uIGdvaW5nIHN1cHByZXNzIGluIGEgc3Vw cHJlc3Npb24gbWVzc2FnZSBhcmUgc3RhdGVkIGFzIG9wdGlvbmFsIGluIHRoZSB0ZXh0LCBidXQg YXJlIG5vdCBtYXJrZWQgYXMgb3B0aW9uYWwgaW4gdGhlIGZpZ3VyZSB3aXRoIGJyYWNrZXRzLjxi cj48YnI+TGluZ2xpPGJyPjxicj4tLS0tLS0tLS0tPGJyPuWPkeiHquaIkeeahHZpdm/mmbrog73m iYvmnLo8YnI+PGJyPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbee8luWGme+8mjxicj48YnI+PGh0bWwg eG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVD LWh0bWw0MCI+PGhlYWQ+PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0I7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1HQiBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+SSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDYudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWlldGYtbG1hcC1mcmFtZXdvcmstMDYudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPkJhcmJhcmEsIEdyZWcsIEtlbiBhbmQgb3RoZXJzIHdobyYj ODIxNzt2ZSBtYWRlIHN1Z2dlc3Rpb25zIC0gUGxlYXNlIGNvdWxkIHlvdSBkbyBhIHF1aWNrIGNo ZWNrIHRvIG1ha2Ugc3VyZSB3ZSBnb3QgeW91ciBwb2ludHMgcHJvcGVybHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwcmU+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPi0tPC9zcGFuPjEyLjYuJm5ic3A7IEZyb20gLTA1IHRvIC0wNjxvOnA+PC9vOnA+PC9w cmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0InPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQic+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgY2xhcmlmaWVkIHRlcm1pbmxvZ3kgYXJvdW5k IE1lYXN1cmVtZW50IE1ldGhvZHMgYW5kIFRhc2tzLiZuYnNwOyBTaW5jZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhpbiBhIE1ldGhvZCB0aGVyZSBtYXkgYmUg c2V2ZXJhbCBkaWZmZXJlbnQgcm9sZXMgKHJlcXVlc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCByZXNwb25kZXIsIGZvciBpbnN0YW5jZSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0In PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQic+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU3VwcHJlc3Npb246IHRoZXJl IGlzIG5vdyB0aGUgY29uY2VwdCBvZiBhIGZsYWcgKGJvb2xlYW4pIHdoaWNoPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5kaWNhdGVzIHdoZXRoZXIgYSBUYXNrIGlz IGJ5IGRlZmF1bHQgZ2V0cyBzdXBwcmVzc2VkIG9yIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0InPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgb3B0aW9uYWwgc3VwcHJlc3Npb24gbWVzc2FnZSAod2l0 aCBsaXN0IG9mIHNwZWNpZmljIHRhc2tzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgL3NjaGVkdWxlcyB0byBzdXBwcmVzcykgb3Zlci1yaWRlcyB0aGlzIGZsYWcuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0InPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSBwcmV2aW91 cyBidWxsZXQgYWxzbyBtZWFucyB0aGVyZSBpcyBubyBuZWVkIHRvIG1ha2UgYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpc3RpbmN0aW9uIGJldHdlZW4gYWN0aXZl IGFuZCBwYXNzaXZlIE1lYXN1cmVtZW50IFRhc2tzLCBzbyB0aGlzPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCJz4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlzdGluY3Rpb24gaXMgcmVtb3ZlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0In PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQic+SSBub3cgc2VlIGEgZ2xpdGNoISBUaGUgZmluYWwgMiBidWxsZXRz IHNob3VsZCBiZSByZXBsYWNlZCBieTotPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0InPiZuYnNw OyZuYnNwOyBvJm5ic3A7IHJlbW92ZWQgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAmIzgyMTE7IENv bmZpZ3VyYXRpb24gaXMgcGFydCBvZiB0aGUgSW5zdHJ1Y3Rpb24gYW5kIHNvIHVzZXMgdGhlIENv bnRyb2wgUHJvdG9jb2w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------OW90LQDOSB501TMNY019UVWY61UEGQ-- From nobody Sun Jun 15 10:26: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 C15C81B296F for ; Sun, 15 Jun 2014 10:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.798 X-Spam-Level: *** X-Spam-Status: No, score=3.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 LL2Z4SzzLMh1 for ; Sun, 15 Jun 2014 10:26:19 -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 B2EEF1B2962 for ; Sun, 15 Jun 2014 10:26:19 -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 AF7281204B4; Sun, 15 Jun 2014 13:29:23 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 3A9F5E0363; Sun, 15 Jun 2014 13:25:31 -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; Sun, 15 Jun 2014 13:26:18 -0400 From: "MORTON, ALFRED C (AL)" To: =?gb2312?B?tcvB6cDyL0xpbmdsaSBEZW5n?= , philip.eardley , lmap Date: Sun, 15 Jun 2014 13:26:16 -0400 Thread-Topic: =?gb2312?B?W2xtYXBdILvYuLSjuiBuZXcgdmVyc2lvbiBvZiBmcmFtZXdvcms=?= Thread-Index: Ac+HfH5IgHi6Dzq4Qo28R5mGef1laABP/ED9 Message-ID: <2845723087023D4CB5114223779FA9C80189808186@njfpsrvexg8.research.att.com> References: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/ktqo-1lLYkFrm271C_EPVIYYB1I Subject: Re: [lmap] =?gb2312?b?u9i4tKO6IG5ldyB2ZXJzaW9uIG9mIGZyYW1ld29yaw==?= X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 17:26:21 -0000 TGluZ2xpLA0KDQpJbiB0aGUgZmlndXJlIGZvciB0aGUgSW5zdHJ1Y3Rpb24gKDUuMi4yKSwgYSBj b21iaW5hdGlvbiBvZiAgb3B0aW9uYWwgYW5kIA0KbWFuZGF0b3J5IGl0ZW1zIGFyZSBsaXN0ZWQg aW5zaWRlIHRoZSBzcXVhcmUgYnJhY2tldHMuIEl0IHNlZW1zIHRvIGJlIHRoZSANCnNpbWlsYXIg dG8gU3VwcHJlc3Npb24gaW4gNS4yLjIuMS4NCg0KVGhlIGZpZ3VyZXMgYXJlIHByb3RvY29sIG1v ZGVscywgYXMgZGVzY3JpYmVkIGluDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTAx DQoNCndoaWNoIHNheXM6DQogICBUaGUgcHVycG9zZSBvZiBhIHByb3RvY29sIG1vZGVsIGlzIGV4 cGxpY2l0bHkgbm90IHRvIHByb3ZpZGUgYQ0KICAgY29tcGxldGUgb3IgYWx0ZXJuYXRlIGRlc2Ny aXB0aW9uIG9mIHRoZSBwcm90b2NvbCBiZWluZyBkaXNjdXNzZWQuDQogICBJbnN0ZWFkLCBpdCBp cyB0byBwcm92aWRlIGEgYmlnIHBpY3R1cmUgb3ZlcnZpZXcgb2YgdGhlIHByb3RvY29sIHNvDQog ICB0aGF0IHJlYWRlcnMgY2FuIHF1aWNrbHkgdW5kZXJzdGFuZCB0aGUgZXNzZW50aWFsIGVsZW1l bnRzIG9mIGhvdyBpdA0KICAgd29ya3MuDQoNClVzdWFsbHksIGV4cGxpY2l0IHN0YXRlbWVudHMv cmVxdWlyZW1lbnRzIGluIHRoZSB0ZXh0IHRha2UgcHJlY2VkZW50DQppZiB0aGVyZSBpcyBmb3Vu ZCB0byBiZSBzb21lIGFtYmlndWl0eSBpbGx1c3RyYXRlZCBpbiBhIEZpZ3VyZSwgYW5kIHRoZSB0 ZXh0DQppcyBjbGVhciBpbiB0aGlzIGNhc2UuDQoNCmhvcGUgdGhpcyBoZWxwcywNCkFsDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbG1hcCBbbG1h cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgtcvB6cDyL0xpbmdsaSBEZW5nIFtkZW5n bGluZ2xpQGNoaW5hbW9iaWxlLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVuZSAxMywgMjAxNCAxMDo1 MiBQTQ0KVG86IHBoaWxpcC5lYXJkbGV5OyBsbWFwDQpTdWJqZWN0OiBbbG1hcF0gu9i4tKO6IG5l dyB2ZXJzaW9uIG9mIGZyYW1ld29yaw0KDQpIaSBQaGlsLA0KDQpUaGVyZSBpcyBhIHNtYWxsIGlz c3VlIHdpdGggNS4yLjIuMSwgd2hlcmUgdGhlIHN0YXJ0IHRpbWUsIGVuZCB0aW1lIGFuZCBvbiBn b2luZyBzdXBwcmVzcyBpbiBhIHN1cHByZXNzaW9uIG1lc3NhZ2UgYXJlIHN0YXRlZCBhcyBvcHRp b25hbCBpbiB0aGUgdGV4dCwgYnV0IGFyZSBub3QgbWFya2VkIGFzIG9wdGlvbmFsIGluIHRoZSBm aWd1cmUgd2l0aCBicmFja2V0cy4NCg0KTGluZ2xpDQoNCi0tLS0tLS0tLS0NCrei19TO0rXEdml2 b9bHxNzK1rv6DQoNCnBoaWxpcC5lYXJkbGV5QGJ0LmNvbbHg0LSjug0KDQpJIGp1c3QgdXBsb2Fk ZWQgYSBuZXcgdmVyc2lvbg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWxtYXAt ZnJhbWV3b3JrLTA2LnR4dA0KDQpCYXJiYXJhLCBHcmVnLCBLZW4gYW5kIG90aGVycyB3aG+hr3Zl IG1hZGUgc3VnZ2VzdGlvbnMgLSBQbGVhc2UgY291bGQgeW91IGRvIGEgcXVpY2sgY2hlY2sgdG8g bWFrZSBzdXJlIHdlIGdvdCB5b3VyIHBvaW50cyBwcm9wZXJseQ0KDQpUaGFua3MNClBoaWwNCg0K DQotLTEyLjYuICBGcm9tIC0wNSB0byAtMDYNCg0KICAgbyAgY2xhcmlmaWVkIHRlcm1pbmxvZ3kg YXJvdW5kIE1lYXN1cmVtZW50IE1ldGhvZHMgYW5kIFRhc2tzLiAgU2luY2UNCiAgICAgIHdpdGhp biBhIE1ldGhvZCB0aGVyZSBtYXkgYmUgc2V2ZXJhbCBkaWZmZXJlbnQgcm9sZXMgKHJlcXVlc3Rl cg0KICAgICAgYW5kIHJlc3BvbmRlciwgZm9yIGluc3RhbmNlKQ0KDQogICBvICBTdXBwcmVzc2lv bjogdGhlcmUgaXMgbm93IHRoZSBjb25jZXB0IG9mIGEgZmxhZyAoYm9vbGVhbikgd2hpY2gNCiAg ICAgIGluZGljYXRlcyB3aGV0aGVyIGEgVGFzayBpcyBieSBkZWZhdWx0IGdldHMgc3VwcHJlc3Nl ZCBvciBub3QuDQogICAgICBUaGUgb3B0aW9uYWwgc3VwcHJlc3Npb24gbWVzc2FnZSAod2l0aCBs aXN0IG9mIHNwZWNpZmljIHRhc2tzDQogICAgICAvc2NoZWR1bGVzIHRvIHN1cHByZXNzKSBvdmVy LXJpZGVzIHRoaXMgZmxhZy4NCg0KICAgbyAgVGhlIHByZXZpb3VzIGJ1bGxldCBhbHNvIG1lYW5z IHRoZXJlIGlzIG5vIG5lZWQgdG8gbWFrZSBhDQogICAgICBkaXN0aW5jdGlvbiBiZXR3ZWVuIGFj dGl2ZSBhbmQgcGFzc2l2ZSBNZWFzdXJlbWVudCBUYXNrcywgc28gdGhpcw0KICAgICAgZGlzdGlu Y3Rpb24gaXMgcmVtb3ZlZC4NCg0KSSBub3cgc2VlIGEgZ2xpdGNoISBUaGUgZmluYWwgMiBidWxs ZXRzIHNob3VsZCBiZSByZXBsYWNlZCBieTotDQoNCiAgIG8gIHJlbW92ZWQgQ29uZmlndXJhdGlv biBQcm90b2NvbCCoQyBDb25maWd1cmF0aW9uIGlzIHBhcnQgb2YgdGhlIEluc3RydWN0aW9uIGFu ZCBzbyB1c2VzIHRoZSBDb250cm9sIFByb3RvY29sDQoNCg== From nobody Mon Jun 16 02:25:47 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 0D6401B29B5 for ; Mon, 16 Jun 2014 02:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.671 X-Spam-Level: ** X-Spam-Status: No, score=2.671 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 eLlbvq-Xd6xU for ; Mon, 16 Jun 2014 02:25:43 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 96A8E1A0324 for ; Mon, 16 Jun 2014 02:25:42 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2539eb7f3c21-e3c21; Mon, 16 Jun 2014 17:25:08 +0800 (CST) X-RM-TRANSID: 2ee2539eb7f3c21-e3c21 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2539eb7f2548-e4685; Mon, 16 Jun 2014 17:25:08 +0800 (CST) X-RM-TRANSID: 2ee2539eb7f2548-e4685 From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'MORTON, ALFRED C \(AL\)'" , "'philip.eardley'" , "'lmap'" References: <2845723087023D4CB5114223779FA9C80189808186@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C80189808186@njfpsrvexg8.research.att.com> Date: Mon, 16 Jun 2014 17:25:43 +0800 Message-ID: <004501cf8944$f2a49ed0$d7eddc70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+HfH5IgHi6Dzq4Qo28R5mGef1laABP/ED9ACHHn1A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uXC9TZYB_gmjfGgmIOFbIWOScoc Subject: Re: [lmap] =?utf-8?b?5Zue5aSN77yaIG5ldyB2ZXJzaW9uIG9mIGZyYW1ld29yaw==?= 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, 16 Jun 2014 09:25:47 -0000 Hi Al, Thanks for the clarification. I am fine with the TEXT description in this case. Lingli > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, June 16, 2014 1:26 AM > To: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng; philip.eardley; lmap > Subject: RE: [lmap] =E5=9B=9E=E5=A4=8D=EF=BC=9A new version of = framework >=20 > Lingli, >=20 > In the figure for the Instruction (5.2.2), a combination of optional = and > mandatory items are listed inside the square brackets. It seems to be = the > similar to Suppression in 5.2.2.1. >=20 > The figures are protocol models, as described in > http://tools.ietf.org/html/rfc4101 >=20 > which says: > The purpose of a protocol model is explicitly not to provide a > complete or alternate description of the protocol being discussed. > Instead, it is to provide a big picture overview of the protocol so > that readers can quickly understand the essential elements of how = it > works. >=20 > Usually, explicit statements/requirements in the text take precedent > if there is found to be some ambiguity illustrated in a Figure, and = the text > is clear in this case. >=20 > hope this helps, > Al >=20 >=20 > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of = =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng > [denglingli@chinamobile.com] > Sent: Friday, June 13, 2014 10:52 PM > To: philip.eardley; lmap > Subject: [lmap] =E5=9B=9E=E5=A4=8D=EF=BC=9A new version of framework >=20 > Hi Phil, >=20 > There is a small issue with 5.2.2.1, where the start time, end time = and on going > suppress in a suppression message are stated as optional in the text, = but are > not marked as optional in the figure with brackets. >=20 > Lingli >=20 > ---------- > = =E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84vivo=E6=99=BA=E8=83=BD=E6=89=8B=E6=9C= =BA >=20 > philip.eardley@bt.com=E7=BC=96=E5=86=99=EF=BC=9A >=20 > I just uploaded a new version > http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt >=20 > Barbara, Greg, Ken and others who=E2=80=99ve made suggestions - Please = could you do > a quick check to make sure we got your points properly >=20 > Thanks > Phil >=20 >=20 > --12.6. From -05 to -06 >=20 > o clarified terminlogy around Measurement Methods and Tasks. = Since > within a Method there may be several different roles (requester > and responder, for instance) >=20 > o Suppression: there is now the concept of a flag (boolean) which > indicates whether a Task is by default gets suppressed or not. > The optional suppression message (with list of specific tasks > /schedules to suppress) over-rides this flag. >=20 > o The previous bullet also means there is no need to make a > distinction between active and passive Measurement Tasks, so = this > distinction is removed. >=20 > I now see a glitch! The final 2 bullets should be replaced by:- >=20 > o removed Configuration Protocol =E2=80=93 Configuration is part = of the > Instruction and so uses the Control Protocol From nobody Tue Jun 17 09:47: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 E1D9F1A00A7 for ; Tue, 17 Jun 2014 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 WrNb5RMK9hz5 for ; Tue, 17 Jun 2014 09:47:31 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B505D1A0066 for ; Tue, 17 Jun 2014 09:47:31 -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 s5HGlTom014876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Jun 2014 10:47:30 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A295E1E0049 for ; Tue, 17 Jun 2014 11:47:24 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 811BF1E005B for ; Tue, 17 Jun 2014 11:47:24 -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 s5HGlN4p001737 for ; Tue, 17 Jun 2014 10:47:24 -0600 (MDT) Received: from [10.188.210.78] (x1069818.dhcp.intranet [10.188.210.78]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s5HGlL58001688; Tue, 17 Jun 2014 10:47:22 -0600 (MDT) Message-ID: <53A07119.7030004@centurylink.com> Date: Tue, 17 Jun 2014 10:47:21 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "'lmap@ietf.org'" X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------070507030402010004020702" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-3XJRuKyMqypf0uRHulKbNAohUc Subject: [lmap] Comment on LMAP 06 Suppression 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, 17 Jun 2014 16:47:34 -0000 This is a multi-part message in MIME format. --------------070507030402010004020702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A comment regarding ending immediately and completing a Measurement Task in response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if the option is absent needs to be that the Measurement Task will end immediately, because this will be the more common case. I don't think we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 --------------070507030402010004020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A comment regarding ending immediately and completing a Measurement Task in response to a Suppress.

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)
      immediately (and deletes the associated partial Measurement
      Result(s)).  If absent, the MA completes on-going Measurement
      Tasks.
 

I believe the logic of this option needs to be reversed.  The default if the option is absent needs to be that the Measurement Task will end immediately, because this will be the more common case.  I don’t think we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent.  Perhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measurement Task(s).

      If absent, the MA ends on-going Measurement

      Tasks immediately (and deletes the associated partial Measurement

      Result(s)).

 

Charles 

-- 

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
--------------070507030402010004020702-- From nobody Tue Jun 17 15:57: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 BAF1F1A008F for ; Tue, 17 Jun 2014 15:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 oeJ64ZES2zOF for ; Tue, 17 Jun 2014 15:57:07 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E4B1A007D for ; Tue, 17 Jun 2014 15:57:07 -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 s5HMv3SL006534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 16:57:03 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 66BC91E006F; Tue, 17 Jun 2014 17:56:58 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 4320A1E0069; Tue, 17 Jun 2014 17:56:58 -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 s5HMuvPL004517; Tue, 17 Jun 2014 17:56:57 -0500 (CDT) Received: from [10.188.210.78] (x1069818.dhcp.intranet [10.188.210.78]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s5HMuuDB004448; Tue, 17 Jun 2014 17:56:56 -0500 (CDT) Message-ID: <53A0C7B8.1080403@centurylink.com> Date: Tue, 17 Jun 2014 16:56:56 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , lmap@ietf.org References: <016601cf7bdf$bf0bd1a0$3d2374e0$@com> In-Reply-To: <016601cf7bdf$bf0bd1a0$3d2374e0$@com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/OgvzMWbkLBVPyOsktZoTMth6E_4 Subject: Re: [lmap] FW: New Version Notification for draft-deng-lmap-collaboration-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, 17 Jun 2014 22:57:08 -0000 Lingli, Some thoughts for consideration... I understand the use cases, but I don't know that the proposed implementation in its current state provides benefit. Conceptually, the proposed implementation looks like a super Controller (the Initiator) controlling multiple LMAP Controllers and a super Collector (the Reporter) controlling and aggregating multiple LMAP Collectors. It's like we are adding another layer of management. It may help to provide a better distinction between messages between Initiators and Controller and the words measurement tasks or sub-tasks. It was confusing to me because when the term Measurement Sub-task was used, I thought of a sub-task of an LMAP Measurement Task and LMAP does not have the concept of sub-tasks. So there may need to be a change in some of the terminology to minimize confusion. Charles On 5/30/2014 2:18 AM, é‚“çµèŽ‰/Lingli Deng wrote: > Hi all, > > We submitted a new use-case draft for collaborative measurements, and look forward to your review and comments. > > Thanks, > Lingli > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, May 29, 2014 10:21 AM >> To: Rachel Huang; Deng Lingli; Shihui Duan; Shihui Duan; Lingli Deng; Rachel >> Huang >> Subject: New Version Notification for draft-deng-lmap-collaboration-00.txt >> >> >> A new version of I-D, draft-deng-lmap-collaboration-00.txt >> has been successfully submitted by Lingli Deng and posted to the >> IETF repository. >> >> Name: draft-deng-lmap-collaboration >> Revision: 00 >> Title: Use-cases for Collaborative LMAP >> Document date: 2014-05-29 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-deng-lmap-collaboration-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ >> Htmlized: http://tools.ietf.org/html/draft-deng-lmap-collaboration-00 >> >> >> Abstract: >> This document discusses the motivation and use-cases for >> collaborative LMAP practices, where multiple autonomous measurement >> systems collaborate together to help with UoE enhancement by ICPs, >> network performance monitory to guide ISP/Regulator coordination >> between autonomous network domains and/or regulatory policies and >> cross-boundary troubleshooting for complaints from end consumers. >> >> >> >> >> >> 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. >> >> The IETF Secretariat > > > > _______________________________________________ > 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 Wed Jun 18 03:43: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 591211A018E for ; Wed, 18 Jun 2014 03:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 obE63JNJ0fYP for ; Wed, 18 Jun 2014 03:43:53 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A2A2B1A0171 for ; Wed, 18 Jun 2014 03:43:51 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253a16d3afe4-14fe4; Wed, 18 Jun 2014 18:43:07 +0800 (CST) X-RM-TRANSID: 2ee253a16d3afe4-14fe4 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153a16d34f5b-fe32d; Wed, 18 Jun 2014 18:43:07 +0800 (CST) X-RM-TRANSID: 2ee153a16d34f5b-fe32d From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: , References: <016601cf7bdf$bf0bd1a0$3d2374e0$@com> <53A0C7B8.1080403@centurylink.com> In-Reply-To: <53A0C7B8.1080403@centurylink.com> Date: Wed, 18 Jun 2014 18:43:42 +0800 Message-ID: <012e01cf8ae2$2c734eb0$8559ec10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+Kf2GaWQZGPR0ER4S7eY9u8+VcWAAX/Vrw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/HSE3yarn2J_51upSssxjmkiJ0d0 Subject: Re: [lmap] FW: New Version Notification for draft-deng-lmap-collaboration-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, 18 Jun 2014 10:43:55 -0000 Hi Charles, Thanks for your review. More inline. Lingli > -----Original Message----- > From: Charles Cook [mailto:charles.cook2@centurylink.com] > Sent: Wednesday, June 18, 2014 6:57 AM > To: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng; lmap@ietf.org > Subject: Re: [lmap] FW: New Version Notification for > draft-deng-lmap-collaboration-00.txt >=20 > Lingli, >=20 > Some thoughts for consideration... >=20 > I understand the use cases, but I don't know that the proposed > implementation in its current state provides benefit. Conceptually, [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Thanks. The focus of the = current draft is actually on the use-cases side, and the proposed = architecture included as it is now only serves as a basis for more = discussion. > the proposed implementation looks like a super Controller (the > Initiator) controlling multiple LMAP Controllers and a super Collector > (the Reporter) controlling and aggregating multiple LMAP Collectors. > It's like we are adding another layer of management. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Indeed, as for the current = proposal, which is on the discussion table, is a very intuitive one. The = "another layer of management" is added on purpose to keep = function/requirements to a LMAP MA to a minimum wherever possible. >=20 > It may help to provide a better distinction between messages between > Initiators and Controller and the words measurement tasks or = sub-tasks. > It was confusing to me because when the term Measurement Sub-task was > used, I thought of a sub-task of an LMAP Measurement Task and LMAP = does > not have the concept of sub-tasks. So there may need to be a change = in > some of the terminology to minimize confusion. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] Sorry for the confusion. By = sub-task, we meant an LMAP Measurement Task (which is specific to a LMAP = MA from a LMAP Controller). Shall try to keep aligned with LMAP = terminology in the next revision shortly. >=20 > Charles >=20 >=20 > On 5/30/2014 2:18 AM, =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng wrote: > > Hi all, > > > > We submitted a new use-case draft for collaborative measurements, = and look > forward to your review and comments. > > > > Thanks, > > Lingli > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Thursday, May 29, 2014 10:21 AM > >> To: Rachel Huang; Deng Lingli; Shihui Duan; Shihui Duan; Lingli = Deng; Rachel > >> Huang > >> Subject: New Version Notification for = draft-deng-lmap-collaboration-00.txt > >> > >> > >> A new version of I-D, draft-deng-lmap-collaboration-00.txt > >> has been successfully submitted by Lingli Deng and posted to the > >> IETF repository. > >> > >> Name: draft-deng-lmap-collaboration > >> Revision: 00 > >> Title: Use-cases for Collaborative LMAP > >> Document date: 2014-05-29 > >> Group: Individual Submission > >> Pages: 11 > >> URL: > >> = http://www.ietf.org/internet-drafts/draft-deng-lmap-collaboration-00.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-deng-lmap-collaboration/ > >> Htmlized: > http://tools.ietf.org/html/draft-deng-lmap-collaboration-00 > >> > >> > >> Abstract: > >> This document discusses the motivation and use-cases for > >> collaborative LMAP practices, where multiple autonomous > measurement > >> systems collaborate together to help with UoE enhancement by = ICPs, > >> network performance monitory to guide ISP/Regulator coordination > >> between autonomous network domains and/or regulatory policies = and > >> cross-boundary troubleshooting for complaints from end = consumers. > >> > >> > >> > >> > >> > >> 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. > >> > >> The IETF Secretariat > > > > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- >=20 > 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 Wed Jun 18 11:07: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 B97F11A0280 for ; Wed, 18 Jun 2014 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 Z-v0C3KvME5Y for ; Wed, 18 Jun 2014 11:07:45 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4AC1A0261 for ; Wed, 18 Jun 2014 11:07:45 -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 175d1a35.2b13f5cb5940.121028.00-2452.339179.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 18 Jun 2014 18:07:45 +0000 (UTC) X-MXL-Hash: 53a1d5712fc2b721-a4d97f1252eff600c042888804e8c0d057d12b16 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 c65d1a35.0.120975.00-2269.339002.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 18 Jun 2014 18:07:41 +0000 (UTC) X-MXL-Hash: 53a1d56d1959371e-afce0d2bdff5174f4ce5ccda2b86b873c236e8d8 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 s5II7dbl027737; Wed, 18 Jun 2014 14:07:39 -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 s5II7WDp027565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2014 14:07:37 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 18 Jun 2014 18:07:16 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.91]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 14:07:16 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7g Date: Wed, 18 Jun 2014 18:07:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.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.61.166.174] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DF7CAFGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LbmLHEji c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=uXQnFqASuNsA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAA] X-AnalysisOut: [AA:8 a=MJpyHF2NiE7WACjqefgA:9 a=CjuIK1q_8ugA:10 a=lZB815dz] X-AnalysisOut: [VvQA:10 a=W1qU_X6G3J8A:10 a=HRwqoL5Dgj-RAjpm:21 a=_tSbpjlm] X-AnalysisOut: [ywctOkHv:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=9w5SIOGsvU] X-AnalysisOut: [H9iWk7qwAA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Y] X-AnalysisOut: [k6K0A:10 a=frz4AuCg-hUA:10 a=FywBgKcpKQEA:10 a=VKSsHDBp8ro] X-AnalysisOut: [aDTB9:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/FxzLVsw5m50zWxMYxpgFnisgHdM Subject: Re: [lmap] new version of 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: Wed, 18 Jun 2014 18:07:49 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DF7CAFGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have just 2 comments. I'm also emailing a marked up Word version to the a= uthors, that notes all nits that I found. ------ 5.6.1. End-user-controlled measurement system ... 1. an end-user could somehow request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. Note that a user can't directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA. In a comment to the -04 version I'd asked to have the last sentence deleted= . I didn't really follow up on this among all the other comments. But I sti= ll find this to be an unnecessary restriction. We have lots of devices that= could be considered to have MAs that have both a "controller" interface th= at allows for all Controller - MA activities, and a local user interface fo= r a limited set of user-requested actions. I don't think this should become= prohibited and that we should be forced to remove such a local user interf= ace just to make the MA "compliant" to this framework. This is an unnecessa= ry sentence. ------ 7. Security considerations ... Since Collectors will be contacted repeatedly by MAs using the Collection Protocol to convey their recent results, a successful attack to exhaust the communication resources would prevent a critical operation: reporting. Therefore, all LMAP Collectors should implement technical mechanisms to: o limit the number of reporting connections from a single MA (simultaneous, and connections per unit time). o limit the transmission rate from a single MA. o limit the memory/storage consumed by a single MA's reports. o efficiently reject reporting connections from unknown sources. o separate resources if multiple authentication strengths are used, where the resources should be separated according to each class of strength. o limit iteration counters to generate keys with both a lower and upper limit, to prevent an attacking system from requesting the maximum and causing the Controller to stall on the process (see section 6 of [RFC5357]). Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. The list above this last paragraph is all related to the MA to Collector in= terface. In the context of that interface, per descriptions in 5.5, these c= onsiderations are applicable to the "push" model (where the MA contacts the= Collector) and not the "pull" model. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, June 13, 2014 8:39 AM To: lmap@ietf.org Subject: [lmap] new version of framework I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt Barbara, Greg, Ken and others who've made suggestions - Please could you do= a quick check to make sure we got your points properly Thanks Phil --12.6. From -05 to -06 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. I now see a glitch! The final 2 bullets should be replaced by:- o removed Configuration Protocol - Configuration is part of the Instruc= tion and so uses the Control Protocol ________________________________ --_000_2D09D61DDFA73D4C884805CC7865E61130DF7CAFGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have just 2 comments= . I’m also emailing a marked up Word version to the authors, that not= es all nits that I found.

------

5.6.1.  End-user-controlled measurement system

...

   1.  an end-user could somehow request the ISP- (or reg= ulator-) run

       measurement system to test his/her = line.  The ISP (or regulator)

       Controller would then send an Instr= uction to the MA in the usual

       LMAP way.  Note that a user ca= n't directly initiate a Measurement

       Task on an ISP- (or regulator-) con= trolled MA.

 

In a comment to the -0= 4 version I’d asked to have the last sentence deleted. I didn’t= really follow up on this among all the other comments. But I still find th= is to be an unnecessary restriction. We have lots of devices that could be considered to have MAs that have both a “co= ntroller” interface that allows for all Controller - MA activities, a= nd a local user interface for a limited set of user-requested actions. I do= n’t think this should become prohibited and that we should be forced to remove such a local user interface just to mak= e the MA “compliant” to this framework. This is an unnecessary = sentence.

------

7.  Security considerations

...

   Since Collectors will be contacted repeatedly by MAs using = the

   Collection Protocol to convey their recent results, a succe= ssful

   attack to exhaust the communication resources would prevent= a

   critical operation: reporting.  Therefore, all LMAP Co= llectors should

   implement technical mechanisms to:

 

   o  limit the number of reporting connections from a si= ngle MA

      (simultaneous, and connections per unit t= ime).

 

   o  limit the transmission rate from a single MA.<= /o:p>

 

   o  limit the memory/storage consumed by a single MA's = reports.

 

   o  efficiently reject reporting connections from unkno= wn sources.

 

   o  separate resources if multiple authentication stren= gths are used,

      where the resources should be separated a= ccording to each class of

      strength.

 

   o  limit iteration counters to generate keys with both= a lower and

      upper limit, to prevent an attacking syst= em from requesting the

      maximum and causing the Controller to sta= ll on the process (see

      section 6 of [RFC5357]).

 

   Many of the above considerations are applicable to a "= pull" model,

   where the MA must contact the Controller because NAT or oth= er network

   aspect prevents Controllers from contacting MAs directly.

 

The list above this la= st paragraph is all related to the MA to Collector interface. In the contex= t of that interface, per descriptions in 5.5, these considerations are appl= icable to the “push” model (where the MA contacts the Collector) and not the “pull” model.

 

Barbara

 

 

From: lmap [ma= ilto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Friday, June 13, 2014 8:39 AM
To: lmap@ietf.org
Subject: [lmap] new version of framework

 

I just uploaded a new vers= ion

http://www.ietf.org/id/draft-ietf= -lmap-framework-06.txt

 

Barbara, Greg, Ken and oth= ers who’ve made suggestions - Please could you do a quick check to ma= ke sure we got your points properly

 

Thanks

Phil

  

--12.6.  Fr=
om -05 to -06

 

   o&n= bsp; clarified terminlogy around Measurement Methods and Tasks.  Since=

  &nbs= p;   within a Method there may be several different roles (reques= ter

  &nbs= p;   and responder, for instance)

 

   o&n= bsp; Suppression: there is now the concept of a flag (boolean) which

  &nbs= p;   indicates whether a Task is by default gets suppressed or no= t.

  &nbs= p;   The optional suppression message (with list of specific task= s

  &nbs= p;   /schedules to suppress) over-rides this flag.

 

   o&n= bsp; The previous bullet also means there is no need to make a

  &nbs= p;   distinction between active and passive Measurement Tasks, so= this

  &nbs= p;   distinction is removed.

 

I now see a glit= ch! The final 2 bullets should be replaced by:-

 

   o&n= bsp; removed Configuration Protocol – Configuration is part of the In= struction and so uses the Control Protocol

 

--_000_2D09D61DDFA73D4C884805CC7865E61130DF7CAFGAALPA1MSGUSRBF_-- From nobody Wed Jun 18 18:36: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 597D51A025C for ; Wed, 18 Jun 2014 18:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 PESDIw72j9Vy for ; Wed, 18 Jun 2014 18:36:13 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 7BF291A0087 for ; Wed, 18 Jun 2014 18:36:11 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee153a23e5fec9-ccec9; Thu, 19 Jun 2014 09:35:27 +0800 (CST) X-RM-TRANSID: 2ee153a23e5fec9-ccec9 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153a23e5ca2d-00dff; Thu, 19 Jun 2014 09:35:27 +0800 (CST) X-RM-TRANSID: 2ee153a23e5ca2d-00dff From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'STARK, BARBARA H'" , , References: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 19 Jun 2014 09:36:03 +0800 Message-ID: <016501cf8b5e$d57253e0$8056fba0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01CF8BA1.E39593E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7gAA915FA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/LnzjXPpbzKltG5FiOQCTtZLIB0w Subject: Re: [lmap] new version of 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, 19 Jun 2014 01:36:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0166_01CF8BA1.E39593E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Thursday, June 19, 2014 2:07 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] new version of framework =20 I have just 2 comments. I=E2=80=99m also emailing a marked up Word = version to the authors, that notes all nits that I found. ------ 5.6.1. End-user-controlled measurement system ... 1. an end-user could somehow request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. Note that a user can't directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA. =20 In a comment to the -04 version I=E2=80=99d asked to have the last = sentence deleted. I didn=E2=80=99t really follow up on this among all = the other comments. But I still find this to be an unnecessary = restriction. We have lots of devices that could be considered to have = MAs that have both a =E2=80=9Ccontroller=E2=80=9D interface that allows = for all Controller - MA activities, and a local user interface for a = limited set of user-requested actions. I don=E2=80=99t think this should = become prohibited and that we should be forced to remove such a local = user interface just to make the MA =E2=80=9Ccompliant=E2=80=9D to this = framework. This is an unnecessary sentence. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I don=E2=80=99t see it as a = restriction on implementation. It only reads to me that LMAP would not = standardize the direct user-MA interface. =20 ------ 7. Security considerations ... Since Collectors will be contacted repeatedly by MAs using the Collection Protocol to convey their recent results, a successful attack to exhaust the communication resources would prevent a critical operation: reporting. Therefore, all LMAP Collectors should implement technical mechanisms to: =20 o limit the number of reporting connections from a single MA (simultaneous, and connections per unit time). =20 o limit the transmission rate from a single MA. =20 o limit the memory/storage consumed by a single MA's reports. =20 o efficiently reject reporting connections from unknown sources. =20 o separate resources if multiple authentication strengths are used, where the resources should be separated according to each class of strength. =20 o limit iteration counters to generate keys with both a lower and upper limit, to prevent an attacking system from requesting the maximum and causing the Controller to stall on the process (see section 6 of [RFC5357]). =20 Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. =20 The list above this last paragraph is all related to the MA to Collector = interface. In the context of that interface, per descriptions in 5.5, = these considerations are applicable to the =E2=80=9Cpush=E2=80=9D model = (where the MA contacts the Collector) and not the =E2=80=9Cpull=E2=80=9D = model. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I agree. And I believe I made = the same comment back in May. = http://www.ietf.org/mail-archive/web/lmap/current/msg01418.html=20 =20 Barbara =20 =20 From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Friday, June 13, 2014 8:39 AM To: lmap@ietf.org Subject: [lmap] new version of framework =20 I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt =20 Barbara, Greg, Ken and others who=E2=80=99ve made suggestions - Please = could you do a quick check to make sure we got your points properly =20 Thanks Phil =20 --12.6. From -05 to -06 =20 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) =20 o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. =20 o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. =20 I now see a glitch! The final 2 bullets should be replaced by:- =20 o removed Configuration Protocol =E2=80=93 Configuration is part of = the Instruction and so uses the Control Protocol =20 ------=_NextPart_000_0166_01CF8BA1.E39593E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA = H
Sent: Thursday, June 19, 2014 2:07 AM
To: = philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] new = version of framework

 

I have just = 2 comments. I=E2=80=99m also emailing a marked up Word version to the = authors, that notes all nits that I found.

------

5.6.1.  End-user-controlled measurement = system

...

   1.  an end-user could somehow request the ISP- = (or regulator-) run

       measurement system to test = his/her line.  The ISP (or regulator)

       Controller would then send an = Instruction to the MA in the usual

       LMAP way.  Note that a = user can't directly initiate a Measurement

       Task on an ISP- (or = regulator-) controlled MA.

 

In a comment to the -04 version = I=E2=80=99d asked to have the last sentence deleted. I didn=E2=80=99t = really follow up on this among all the other comments. But I still find = this to be an unnecessary restriction. We have lots of devices that = could be considered to have MAs that have both a = =E2=80=9Ccontroller=E2=80=9D interface that allows for all Controller - = MA activities, and a local user interface for a limited set of = user-requested actions. I don=E2=80=99t think this should become = prohibited and that we should be forced to remove such a local user = interface just to make the MA =E2=80=9Ccompliant=E2=80=9D to this = framework. This is an unnecessary sentence.

[=E9= =82=93=E7=81=B5=E8=8E=89/Lingli Deng] I don=E2=80=99t = see it as a restriction on implementation. It only reads to me that LMAP = would not standardize the direct user-MA interface.

 

------

7.  Security considerations

...

   Since = Collectors will be contacted repeatedly by MAs using = the

   Collection Protocol to = convey their recent results, a successful

   attack to exhaust the communication resources would = prevent a

   critical = operation: reporting.  Therefore, all LMAP Collectors = should

   implement technical = mechanisms to:

 

   o  = limit the number of reporting connections from a single = MA

      = (simultaneous, and connections per unit time).

 

   o  = limit the transmission rate from a single MA.

 

   o  = limit the memory/storage consumed by a single MA's = reports.

 

   o  efficiently reject reporting connections from = unknown sources.

 

   o  = separate resources if multiple authentication strengths are = used,

      where = the resources should be separated according to each class = of

      = strength.

 

   o  = limit iteration counters to generate keys with both a lower = and

      upper = limit, to prevent an attacking system from requesting = the

      = maximum and causing the Controller to stall on the process = (see

  =     section 6 of [RFC5357]).

 

   Many of = the above considerations are applicable to a "pull" = model,

   where the MA must = contact the Controller because NAT or other = network

   aspect prevents = Controllers from contacting MAs directly.

 

The list above this last paragraph = is all related to the MA to Collector interface. In the context of that = interface, per descriptions in 5.5, these considerations are applicable = to the =E2=80=9Cpush=E2=80=9D model (where the MA contacts the = Collector) and not the =E2=80=9Cpull=E2=80=9D = model.

[=E9= =82=93=E7=81=B5=E8=8E=89/Lingli Deng] I agree. And I = believe I made the same comment back in May. = http://www.ietf.org/mail-archive/web/lmap/current/msg01418.html =

 

Barbara

 

 

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: Friday, June 13, 2014 8:39 = AM
To: lmap@ietf.org
Subject: [lmap] new version of = framework

 

I just = uploaded a new version

http://w= ww.ietf.org/id/draft-ietf-lmap-framework-06.txt

=

 

Barbara, = Greg, Ken and others who=E2=80=99ve made suggestions - Please could you = do a quick check to make sure we got your points = properly

 

Thanks

Phil

 

--12.6.  From -05 to -06

 

   o  clarified terminlogy around Measurement = Methods and Tasks.  Since

      within a Method there may be = several different roles (requester

      and responder, for = instance)

 

   o  Suppression: there is now the concept of a = flag (boolean) which

      indicates whether a Task is by = default gets suppressed or not.

      The optional suppression message = (with list of specific tasks

      /schedules to suppress) over-rides = this flag.

 

   o  The previous bullet also means there is no = need to make a

      distinction between active and = passive Measurement Tasks, so this

      distinction is = removed.

 

I now = see a glitch! The final 2 bullets should be replaced = by:-

 

   o  removed Configuration Protocol =E2=80=93 = Configuration is part of the Instruction and so uses the Control = Protocol

 

------=_NextPart_000_0166_01CF8BA1.E39593E0-- From nobody Thu Jun 19 05:34: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 BF2591A0393 for ; Thu, 19 Jun 2014 05:33:57 -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 OVu-J7zQoeLR for ; Thu, 19 Jun 2014 05:33:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9B51A0385 for ; Thu, 19 Jun 2014 05:33:53 -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.181.6; Thu, 19 Jun 2014 13:29:52 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Thu, 19 Jun 2014 13:33:12 +0100 From: To: , Date: Thu, 19 Jun 2014 13:33:11 +0100 Thread-Topic: [lmap] Comment on LMAP 06 Suppression Thread-Index: Ac+KS9pyrEQnBcWKSJihjbGHJ/n5uABbZBEg Message-ID: References: <53A07119.7030004@centurylink.com> In-Reply-To: <53A07119.7030004@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: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BC9FEMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_9ZAIjuglUyM6uYLq22Ie7LvGJA Subject: Re: [lmap] Comment on LMAP 06 Suppression 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, 19 Jun 2014 12:33:57 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BC9FEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, I think it's marginally better to keep as-is, so by default suppression doe= sn't impact on-going measurement tasks. Reason is that it's very simple for a MA to stop new Tasks starting (it bar= ely has to do anything), but it may be a bit harder for it to stop on-going= Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c). I guess also it might have a task that essentially runs for ever, such as a= basic connectivity check - but of course this depends how the operator has= defined their tasks and schedules. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: 17 June 2014 17:47 To: 'lmap@ietf.org' Subject: [lmap] Comment on LMAP 06 Suppression A comment regarding ending immediately and completing a Measurement Task in= response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if th= e option is absent needs to be that the Measurement Task will end immediate= ly, because this will be the more common case. I don't think we want to re= quire an option to be set to immediately end all unflagged Measurement Task= s when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BC9FEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Charles,

 

I think it’s marginally better to keep as-is, so by default s= uppression doesn’t impact on-going measurement tasks.

Reason is that it’s ver= y simple for a MA to stop new Tasks starting (it barely has to do anything)= , but it may be a bit harder for it to stop on-going Tasks (at least if it = wants to make sure they stop cleanly, perhaps clean up state in the MA, per= haps shut down connections with the remote server etc).

I guess also it might have a task= that essentially runs for ever, such as a basic connectivity check –= but of course this depends how the operator has defined their tasks and sc= hedules.

=  

Thanks<= /o:p>

phil

 

=

 

=

From: lmap [mailto:lmap-boun= ces@ietf.org] On Behalf Of Charles Cook
Sent: 17 June 2014= 17:47
To: 'lmap@ietf.org'
Subject: [lmap] Comment on L= MAP 06 Suppression

 

A comment regarding ending immediat= ely and completing a Measurement Task in response to a Suppress.=

 

   o  a demand that the MA en= ds its on-going Active Measurement Task(s)
     = ; immediately (and deletes the associated partial Measurement
 &nbs= p;    Result(s)).  If absent, the MA completes on-going= Measurement
      Tasks.
 =

I believe the logic of this option needs to be reversed.&n= bsp; The default if the option is absent needs to be that the Measurement T= ask will end immediately, because this will be the more common case.  = I don’t think we want to require an option to be set to immediately e= nd all unflagged Measurement Tasks when a simple Suppress is sent.  Pe= rhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measu= rement Task(s).

      If abse= nt, the MA ends on-going Measurement

   = ;   Tasks immediately (and deletes the associated partial Measure= ment

      Result(s)). <= /o:p>

 

Charles 


--
= 
 
Charles Cook 
Princip=
al Architect
Network
5325 Zuni St=
reet; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@centur=
ylink.com
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BC9FEMV67UKRDdoma_-- From nobody Thu Jun 19 05:43: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 639CA1A039A for ; Thu, 19 Jun 2014 05:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 DQO7WHiAn3Lm for ; Thu, 19 Jun 2014 05:43:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7170D1A0393 for ; Thu, 19 Jun 2014 05:43:34 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 19 Jun 2014 13:43:40 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 19 Jun 2014 13:43:32 +0100 From: To: , Date: Thu, 19 Jun 2014 13:43:31 +0100 Thread-Topic: new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7gACcz11A= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.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_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BCA7EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/u6bm8fVR7Ev3MmtNLPKEEnRg50Q Subject: Re: [lmap] new version of 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, 19 Jun 2014 12:43:40 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BCA7EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barbara, Thanks for the comments - and for the nits (which I'll look at later) On the first, sorry to have missed this, happy to delete the offending sent= ence. On the second, I actually think most of these considerations are applicable= whether the mA "pushes" the results or whether the Collector "pulls" them. Certainly << limit the memory/storage consumed by a single MA's reports>> a= lso I think the transmission rate. I guess limiting the number of connectio= ns from a MA is more applicable to push (at least is simple in the pull cas= e!) Maybe the best thing is simply to delete the final paragraph - don't think = it adds anything that hasn't been said elsewhere. So delete << Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. >> phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 18 June 2014 19:07 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: new version of framework I have just 2 comments. I'm also emailing a marked up Word version to the a= uthors, that notes all nits that I found. ------ 5.6.1. End-user-controlled measurement system ... 1. an end-user could somehow request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. Note that a user can't directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA. In a comment to the -04 version I'd asked to have the last sentence deleted= . I didn't really follow up on this among all the other comments. But I sti= ll find this to be an unnecessary restriction. We have lots of devices that= could be considered to have MAs that have both a "controller" interface th= at allows for all Controller - MA activities, and a local user interface fo= r a limited set of user-requested actions. I don't think this should become= prohibited and that we should be forced to remove such a local user interf= ace just to make the MA "compliant" to this framework. This is an unnecessa= ry sentence. ------ 7. Security considerations ... Since Collectors will be contacted repeatedly by MAs using the Collection Protocol to convey their recent results, a successful attack to exhaust the communication resources would prevent a critical operation: reporting. Therefore, all LMAP Collectors should implement technical mechanisms to: o limit the number of reporting connections from a single MA (simultaneous, and connections per unit time). o limit the transmission rate from a single MA. o limit the memory/storage consumed by a single MA's reports. o efficiently reject reporting connections from unknown sources. o separate resources if multiple authentication strengths are used, where the resources should be separated according to each class of strength. o limit iteration counters to generate keys with both a lower and upper limit, to prevent an attacking system from requesting the maximum and causing the Controller to stall on the process (see section 6 of [RFC5357]). Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. The list above this last paragraph is all related to the MA to Collector in= terface. In the context of that interface, per descriptions in 5.5, these c= onsiderations are applicable to the "push" model (where the MA contacts the= Collector) and not the "pull" model. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, June 13, 2014 8:39 AM To: lmap@ietf.org Subject: [lmap] new version of framework I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt Barbara, Greg, Ken and others who've made suggestions - Please could you do= a quick check to make sure we got your points properly Thanks Phil --12.6. From -05 to -06 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. I now see a glitch! The final 2 bullets should be replaced by:- o removed Configuration Protocol - Configuration is part of the Instruc= tion and so uses the Control Protocol --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BCA7EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= /body>= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D40F4D2BCA7EMV67UKRDdoma_-- From nobody Thu Jun 19 05:52: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 EE22F1A03A0 for ; Thu, 19 Jun 2014 05:52:12 -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, HTML_MESSAGE=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 ss-d7LpgWPcz for ; Thu, 19 Jun 2014 05:52:10 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B9A1A0395 for ; Thu, 19 Jun 2014 05:52:09 -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 s5JCq4Wv024287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 06:52:05 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6E7821E005F; Thu, 19 Jun 2014 07:51:59 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5AAD01E0049; Thu, 19 Jun 2014 07:51:59 -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 s5JCpw3P004917; Thu, 19 Jun 2014 07:51:59 -0500 (CDT) Received: from [10.188.194.20] (x1069818.dhcp.intranet [10.188.194.20]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s5JCpuhm004839; Thu, 19 Jun 2014 07:51:56 -0500 (CDT) Message-ID: <53A2DCEA.1090500@centurylink.com> Date: Thu, 19 Jun 2014 06:51:54 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: philip.eardley@bt.com, lmap@ietf.org References: <53A07119.7030004@centurylink.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060905070302030600060400" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/uiv81o6ZCWuPCUO8heART7LnIhs Subject: Re: [lmap] Comment on LMAP 06 Suppression 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: Thu, 19 Jun 2014 12:52:13 -0000 This is a multi-part message in MIME format. --------------060905070302030600060400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil, I'm still not convinced that we should keep the default behavior as is. Particularly because we can set a flag for a Measurement Task to ignore suppression. The real question is which is the more common case: that a Measurement Task needs to stop completely or that a Measurement Task can continue to completion? People may have differing views on this. My view is that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort. That implies stopping the Measurement Task immediately. If it is not a Network Emergency, then the Controller can simply update the Measurement Task Schedule to change when a Measurement Task ends. I also believe that Measurement Tasks that are expected to run to completion can simply have the the ignore Suppression flag set. Consequently, I believe the default response should be reversed so that an optional parameter does not need to be set in order to cause a Measurement Task to cease immediately. Charles On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote: > > Charles, > > > > I think it's marginally better to keep as-is, so by default > suppression doesn't impact on-going measurement tasks. > > Reason is that it's very simple for a MA to stop new Tasks starting > (it barely has to do anything), but it may be a bit harder for it to > stop on-going Tasks (at least if it wants to make sure they stop > cleanly, perhaps clean up state in the MA, perhaps shut down > connections with the remote server etc). > > I guess also it might have a task that essentially runs for ever, such > as a basic connectivity check -- but of course this depends how the > operator has defined their tasks and schedules. > > > > Thanks > > phil > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Charles Cook > *Sent:* 17 June 2014 17:47 > *To:* 'lmap@ietf.org' > *Subject:* [lmap] Comment on LMAP 06 Suppression > > > > A comment regarding ending immediately and completing a Measurement > Task in response to a Suppress. > > > > o a demand that the MA ends its on-going Active Measurement Task(s) > immediately (and deletes the associated partial Measurement > Result(s)). If absent, the MA completes on-going Measurement > Tasks. > > > I believe the logic of this option needs to be reversed. The default > if the option is absent needs to be that the Measurement Task will end > immediately, because this will be the more common case. I don't think > we want to require an option to be set to immediately end all > unflagged Measurement Tasks when a simple Suppress is sent. Perhaps > something like this would work. > > > > o a demand that the MA competes its on-going Active Measurement Task(s). > > If absent, the MA ends on-going Measurement > > Tasks immediately (and deletes the associated partial Measurement > > Result(s)). > > > > Charles > > > -- > > 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 -- 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 --------------060905070302030600060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil,

I'm still not convinced that we should keep the default behavior as is.  Particularly because we can set a flag for a Measurement Task to ignore suppression.

The real question is which is the more common case:  that a Measurement Task needs to stop completely or that a Measurement Task can continue to completion?  People may have differing views on this.  My view is that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort.  That implies stopping the Measurement Task immediately.  If it is not a Network Emergency, then the Controller can simply update the Measurement Task Schedule to change when a Measurement Task ends.  I also believe that Measurement Tasks that are expected to run to completion can simply have the the ignore Suppression flag set. 

Consequently, I believe the default response should be reversed so that an optional parameter does not need to be set in order to cause a Measurement Task to cease immediately.

Charles


On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote:

Charles,

 

I think it’s marginally better to keep as-is, so by default suppression doesn’t impact on-going measurement tasks.

Reason is that it’s very simple for a MA to stop new Tasks starting (it barely has to do anything), but it may be a bit harder for it to stop on-going Tasks (at least if it wants to make sure they stop cleanly, perhaps clean up state in the MA, perhaps shut down connections with the remote server etc).

I guess also it might have a task that essentially runs for ever, such as a basic connectivity check – but of course this depends how the operator has defined their tasks and schedules.

 

Thanks

phil

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: 'lmap@ietf.org'
Subject: [lmap] Comment on LMAP 06 Suppression

 

A comment regarding ending immediately and completing a Measurement Task in response to a Suppress.

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)
      immediately (and deletes the associated partial Measurement
      Result(s)).  If absent, the MA completes on-going Measurement
      Tasks.
 

I believe the logic of this option needs to be reversed.  The default if the option is absent needs to be that the Measurement Task will end immediately, because this will be the more common case.  I don’t think we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent.  Perhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measurement Task(s).

      If absent, the MA ends on-going Measurement

      Tasks immediately (and deletes the associated partial Measurement

      Result(s)).

 

Charles 


-- 
 
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

-- 

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
--------------060905070302030600060400-- From nobody Thu Jun 19 06:28: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 1AB761A0362 for ; Thu, 19 Jun 2014 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 cB_4f-VACVPo for ; Thu, 19 Jun 2014 06:28:06 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2FB1A023A for ; Thu, 19 Jun 2014 06:28:06 -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 665e2a35.2b13c1461940.584842.00-2472.1641165.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 19 Jun 2014 13:28:06 +0000 (UTC) X-MXL-Hash: 53a2e5666c5943fc-20a4896f4f9da3e5db3bba56a1a09be8581c333a 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 d55e2a35.0.584779.00-2210.1640977.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 19 Jun 2014 13:27:59 +0000 (UTC) X-MXL-Hash: 53a2e55f43e8b0ee-aeee7327cb9fba6de8a17b907d6a0daa782e6fd7 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 s5JDRv9T026675; Thu, 19 Jun 2014 09:27:57 -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 s5JDRrjZ026620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 09:27:56 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 19 Jun 2014 13:27:33 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.91]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 09:27:33 -0400 From: "STARK, BARBARA H" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7gACcz11AAAbRtwA== Date: Thu, 19 Jun 2014 13:27:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DF7F64@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.18.187] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DF7F64GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LbmLHEji c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=cDQzkTEPbkwA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAA] X-AnalysisOut: [AA:8 a=xTewy3mN8w3S99KN1B8A:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYl] X-AnalysisOut: [S0cA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=9tqV77o75RNd] X-AnalysisOut: [vrZM:21 a=cPTevirCpPii8-q_:21 a=yMhMjlubAAAA:8 a=SSmOFEACA] X-AnalysisOut: [AAA:8 a=z2tt5jsS7h1ztJQwtw4A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4] X-AnalysisOut: [-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=8t8AQpC2jn9] X-AnalysisOut: [3FpWP:21 a=GDeeCy2yluKmApJw:21 a=3p2dLMOlNvACyETH:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3EAcNFyjQNMFFN8yl7pdrJkzHTk Subject: Re: [lmap] new version of 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, 19 Jun 2014 13:28:11 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DF7F64GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the second, I actually think most of these considerations are applicable= whether the mA "pushes" the results or whether the Collector "pulls" them. Certainly << limit the memory/storage consumed by a single MA's reports>> a= lso I think the transmission rate. I guess limiting the number of connectio= ns from a MA is more applicable to push (at least is simple in the pull cas= e!) Maybe the best thing is simply to delete the final paragraph - don't think = it adds anything that hasn't been said elsewhere. So delete << Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. >> Thanks. The main problem for me was actually that the intro to the li= st was about Collector, the final item in the list was about Controller, an= d the paragraph after the list (about the list) talked about the Controller= . There needs to be consistency -- either the entire list and its intro and= summary paragraphs are about the Collector, about the Controller, or both.= Having the intro and first part of the list being Collector and last item = and summary being Controller is very confusing for me. phil From: STARK, BARBARA H [mailto:bs7652@att.com] Sent: 18 June 2014 19:07 To: Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: RE: new version of framework I have just 2 comments. I'm also emailing a marked up Word version to the a= uthors, that notes all nits that I found. ------ 5.6.1. End-user-controlled measurement system ... 1. an end-user could somehow request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. Note that a user can't directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA. In a comment to the -04 version I'd asked to have the last sentence deleted= . I didn't really follow up on this among all the other comments. But I sti= ll find this to be an unnecessary restriction. We have lots of devices that= could be considered to have MAs that have both a "controller" interface th= at allows for all Controller - MA activities, and a local user interface fo= r a limited set of user-requested actions. I don't think this should become= prohibited and that we should be forced to remove such a local user interf= ace just to make the MA "compliant" to this framework. This is an unnecessa= ry sentence. ------ 7. Security considerations ... Since Collectors will be contacted repeatedly by MAs using the Collection Protocol to convey their recent results, a successful attack to exhaust the communication resources would prevent a critical operation: reporting. Therefore, all LMAP Collectors should implement technical mechanisms to: o limit the number of reporting connections from a single MA (simultaneous, and connections per unit time). o limit the transmission rate from a single MA. o limit the memory/storage consumed by a single MA's reports. o efficiently reject reporting connections from unknown sources. o separate resources if multiple authentication strengths are used, where the resources should be separated according to each class of strength. o limit iteration counters to generate keys with both a lower and upper limit, to prevent an attacking system from requesting the maximum and causing the Controller to stall on the process (see section 6 of [RFC5357]). Many of the above considerations are applicable to a "pull" model, where the MA must contact the Controller because NAT or other network aspect prevents Controllers from contacting MAs directly. The list above this last paragraph is all related to the MA to Collector in= terface. In the context of that interface, per descriptions in 5.5, these c= onsiderations are applicable to the "push" model (where the MA contacts the= Collector) and not the "pull" model. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, June 13, 2014 8:39 AM To: lmap@ietf.org Subject: [lmap] new version of framework I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt Barbara, Greg, Ken and others who've made suggestions - Please could you do= a quick check to make sure we got your points properly Thanks Phil --12.6. From -05 to -06 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. I now see a glitch! The final 2 bullets should be replaced by:- o removed Configuration Protocol - Configuration is part of the Instruc= tion and so uses the Control Protocol --_000_2D09D61DDFA73D4C884805CC7865E61130DF7F64GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the second, = I actually think most of these considerations are applicable whether the mA= “pushes” the results or whether the Collector “pullsR= 21; them.

Certainly <&= lt;limit the memory= /storage consumed by a single MA's reports>> also I think the transmi= ssion rate. I guess limiting the number of connections from a MA is more ap= plicable to push (at least is simple in the pull case!)

=  

= Maybe the best thing is simply to delete the final paragraph – don= 217;t think it adds anything that hasn’t been said elsewhere. So dele= te

<< Many of the above considerations are applicable to a "pull= " model,

   where the MA must contact the Controller because NAT or oth= er network

   aspect prevents Controllers from contacting MAs directly.

>>&n= bsp;

&n= bsp;

<bhs= > Thanks. The main problem for me was actually that the intro to the lis= t was about Collector, the final item in the list was about Controller, and= the paragraph after the list (about the list) talked about the Controller. There needs to be consistency -- either the e= ntire list and its intro and summary paragraphs are about the Collector, ab= out the Controller, or both. Having the intro and first part of the list be= ing Collector and last item and summary being Controller is very confusing for me.</bhs><= /span>

 

phil=

 

From: STARK, B= ARBARA H [mailto:bs7652@att.com]
Sent: 18 June 2014 19:07
To: Eardley,PL,Philip,TUB8 R; lmap@= ietf.org
Subject: RE: new version of framework

 

I have just 2 comments= . I’m also emailing a marked up Word version to the authors, that not= es all nits that I found.

------

5.6.1.  End-user-controlled measurement system

...

   1.  an end-user could somehow request the ISP- (or reg= ulator-) run

       measurement system to test his/her = line.  The ISP (or regulator)

       Controller would then send an Instr= uction to the MA in the usual

       LMAP way.  Note that a user ca= n't directly initiate a Measurement

       Task on an ISP- (or regulator-) con= trolled MA.

 

In a comment to the -0= 4 version I’d asked to have the last sentence deleted. I didn’t= really follow up on this among all the other comments. But I still find th= is to be an unnecessary restriction. We have lots of devices that could be considered to have MAs that have both a “co= ntroller” interface that allows for all Controller - MA activities, a= nd a local user interface for a limited set of user-requested actions. I do= n’t think this should become prohibited and that we should be forced to remove such a local user interface just to mak= e the MA “compliant” to this framework. This is an unnecessary = sentence.

------

7.  Security considerations

...

   Since Collectors will be contacted repeatedly by MAs using = the

   Collection Protocol to convey their recent results, a succe= ssful

   attack to exhaust the communication resources would prevent= a

   critical operation: reporting.  Therefore, all LMAP Co= llectors should

   implement technical mechanisms to:

 

   o  limit the number of reporting connections from a si= ngle MA

      (simultaneous, and connections per unit t= ime).

 

   o  limit the transmission rate from a single MA.<= /o:p>

 

   o  limit the memory/storage consumed by a single MA's = reports.

 

   o  efficiently reject reporting connections from unkno= wn sources.

 

   o  separate resources if multiple authentication stren= gths are used,

      where the resources should be separated a= ccording to each class of

      strength.

 

   o  limit iteration counters to generate keys with both= a lower and

      upper limit, to prevent an attacking syst= em from requesting the

      maximum and causing the Controller to sta= ll on the process (see

      section 6 of [RFC5357]).

 

   Many of the above considerations are applicable to a "= pull" model,

   where the MA must contact the Controller because NAT or oth= er network

   aspect prevents Controllers from contacting MAs directly.

 

The list above this la= st paragraph is all related to the MA to Collector interface. In the contex= t of that interface, per descriptions in 5.5, these considerations are appl= icable to the “push” model (where the MA contacts the Collector) and not the “pull” model.

 

Barbara

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley= @bt.com
Sent: Friday, June 13, 2014 8:39 AM
To: lmap@ietf.org
Subject: [lmap] new version of framework

 

I just uploaded a new vers= ion

http://www.ietf.org/id/draft-ietf= -lmap-framework-06.txt

 

Barbara, Greg, Ken and oth= ers who’ve made suggestions - Please could you do a quick check to ma= ke sure we got your points properly

 

Thanks

Phil

  

--12.6.  Fr=
om -05 to -06

 

   o  clarified terminlogy a= round Measurement Methods and Tasks.  Since

      within a Met= hod there may be several different roles (requester

      and responde= r, for instance)

 

   o  Suppression: there is = now the concept of a flag (boolean) which

      indicates wh= ether a Task is by default gets suppressed or not.

      The optional= suppression message (with list of specific tasks

      /schedules t= o suppress) over-rides this flag.

 

   o  The previous bullet al= so means there is no need to make a

      distinction = between active and passive Measurement Tasks, so this

      distinction = is removed.

 

I now see a glitch! The final 2 bullets sho= uld be replaced by:-

 

   o  removed Configuration = Protocol – Configuration is part of the Instruction and so uses the C= ontrol Protocol

 

--_000_2D09D61DDFA73D4C884805CC7865E61130DF7F64GAALPA1MSGUSRBF_-- From nobody Thu Jun 19 06:39:41 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 31D681A0394 for ; Thu, 19 Jun 2014 06:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 NkISsCOgzx2B for ; Thu, 19 Jun 2014 06:39:37 -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 DB2951A01DE for ; Thu, 19 Jun 2014 06:39:36 -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 CE52A554AEF; Thu, 19 Jun 2014 09:42:56 -0400 (EDT) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id 500B5E0363; Thu, 19 Jun 2014 09:38:45 -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, 19 Jun 2014 09:39:35 -0400 From: "MORTON, ALFRED C (AL)" To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Date: Thu, 19 Jun 2014 09:39:34 -0400 Thread-Topic: [lmap] Comment on LMAP 06 Suppression Thread-Index: Ac+LvVQ3KtbVIr6JRDKh8bBevAkO9wAApvZQ Message-ID: <2845723087023D4CB5114223779FA9C801896A8087@njfpsrvexg8.research.att.com> References: <53A07119.7030004@centurylink.com> <53A2DCEA.1090500@centurylink.com> In-Reply-To: <53A2DCEA.1090500@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C801896A8087njfpsrvexg8re_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/7apKFQWMquqTASXIMcowFnuZOuY Subject: Re: [lmap] Comment on LMAP 06 Suppression 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, 19 Jun 2014 13:39:40 -0000 --_000_2845723087023D4CB5114223779FA9C801896A8087njfpsrvexg8re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, The currently-defined Suppression has a "Panic-button" capability which satisfies your case of a Network Emergency. Perhaps we could make this more clear. If we cast the message starting from Panic/Full-Stop, it seems more unexpected to add options for only on-going tasks, or only certain tasks, or start times, etc. IMO, it's called Suppression now to allow for different degrees of measurement deletion, all the way up to full stop. It also seems tom that it's easier to resume (Unsuppress) the measurement schedule from the current definition of Suppression. Long-term or On-going measurement tasks would probably need to be re-scheduled after a Panic/Full-Stop is withdrawn. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Thursday, June 19, 2014 8:52 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Phil, I'm still not convinced that we should keep the default behavior as is. Pa= rticularly because we can set a flag for a Measurement Task to ignore suppr= ession. The real question is which is the more common case: that a Measurement Tas= k needs to stop completely or that a Measurement Task can continue to compl= etion? People may have differing views on this. My view is that a Suppres= sion is intended to stop the generation of traffic because there is a Netwo= rk emergency of some sort. That implies stopping the Measurement Task imme= diately. If it is not a Network Emergency, then the Controller can simply = update the Measurement Task Schedule to change when a Measurement Task ends= . I also believe that Measurement Tasks that are expected to run to comple= tion can simply have the the ignore Suppression flag set. Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately. Charles On 6/19/2014 6:33 AM, philip.eardley@bt.com w= rote: Charles, I think it's marginally better to keep as-is, so by default suppression doe= sn't impact on-going measurement tasks. Reason is that it's very simple for a MA to stop new Tasks starting (it bar= ely has to do anything), but it may be a bit harder for it to stop on-going= Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c). I guess also it might have a task that essentially runs for ever, such as a= basic connectivity check - but of course this depends how the operator has= defined their tasks and schedules. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: 17 June 2014 17:47 To: 'lmap@ietf.org' Subject: [lmap] Comment on LMAP 06 Suppression A comment regarding ending immediately and completing a Measurement Task in= response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if th= e option is absent needs to be that the Measurement Task will end immediate= ly, because this will be the more common case. I don't think we want to re= quire an option to be set to immediately end all unflagged Measurement Task= s when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 -- 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 --_000_2845723087023D4CB5114223779FA9C801896A8087njfpsrvexg8re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Charles,

 

The currently-defined Suppression has a "Panic-button" capabi= lity

which sati= sfies your case of a Network Emergency. Perhaps we could<= /p>

make this more clear.<= /span>

 

If we cast the message starting fr= om Panic/Full-Stop, it seems more

unexpected to add options for only on-going tasks, or on= ly certain tasks,

or start times, etc. IMO, it's called Suppression now to allow for =

different degrees o= f measurement deletion, all the way up to full stop.

<= p class=3DMsoNormal> 

It also seems tom that it's easier to resume= (Unsuppress) the measurement

schedule from the current definition of Suppression. Long-t= erm or On-going

a Panic/Full-Stop is with= drawn.

&nb= sp;

Al

 

=

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'>From: lmap [mailto:lmap-bounces@ietf.org] On= Behalf Of Charles Cook
Sent: Thursday, June 19, 2014 8:52 AM=
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: = [lmap] Comment on LMAP 06 Suppression

 

Phil,

I'm still not convinced that we should keep the= default behavior as is.  Particularly because we can set a flag for a= Measurement Task to ignore suppression.

The real question is which = is the more common case:  that a Measurement Task needs to stop comple= tely or that a Measurement Task can continue to completion?  People ma= y have differing views on this.  My view is that a Suppression is inte= nded to stop the generation of traffic because there is a Network emergency= of some sort.  That implies stopping the Measurement Task immediately= .  If it is not a Network Emergency, then the Controller can simply up= date the Measurement Task Schedule to change when a Measurement Task ends.&= nbsp; I also believe that Measurement Tasks that are expected to run to com= pletion can simply have the the ignore Suppression flag set. 

= Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote:

Charles,

 

I th= ink it’s marginally better to keep as-is, so by default suppression d= oesn’t impact on-going measurement tasks.

Reason is that it’s very simple for= a MA to stop new Tasks starting (it barely has to do anything), but it may= be a bit harder for it to stop on-going Tasks (at least if it wants to mak= e sure they stop cleanly, perhaps clean up state in the MA, perhaps shut do= wn connections with the remote server etc).

I guess also it might have a task that esse= ntially runs for ever, such as a basic connectivity check – but of co= urse this depends how the operator has defined their tasks and schedules.

 

Thanks

phil

 

 

From: lmap [mailto:lm= ap-bounces@ietf.org] On Behalf Of Charles Cook
Sent: 1= 7 June 2014 17:47
To: 'lmap@ietf= .org'
Subject: [lmap] Comment on LMAP 06 Suppression

 

A comment regarding ending immediately and completing a Measur= ement Task in response to a Suppress.

 

   o  a demand that the MA ends its on-going Act= ive Measurement Task(s)
      immediately (and = deletes the associated partial Measurement
     = ; Result(s)).  If absent, the MA completes on-going Measurement
&nb= sp;     Tasks.
 

I= believe the logic of this option needs to be reversed.  The default i= f the option is absent needs to be that the Measurement Task will end immed= iately, because this will be the more common case.  I don’t thin= k we want to require an option to be set to immediately end all unflagged M= easurement Tasks when a simple Suppress is sent.  Perhaps something li= ke this would work.

 

o = ; a demand that the MA competes its on-going Active Measurement Task(s).

      If absent, the MA ends on= -going Measurement

      Task= s immediately (and deletes the associated partial Measurement

      Result(s)).

&= nbsp;

Charl= es 



-- 
=
 
Charles Cook 
Principal Ar=
chitect
Network
5325 Zuni Street;=
 Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662charles.cook2@centurylink= .com



-- 
=
 
Charles Cook 
Principal Ar=
chitect
Network
5325 Zuni Street;=
 Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662charles.cook2@centurylink= .com
= --_000_2845723087023D4CB5114223779FA9C801896A8087njfpsrvexg8re_-- From nobody Thu Jun 19 06:40: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 31DFB1A011B for ; Thu, 19 Jun 2014 06:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 goqQFwYJWaXQ for ; Thu, 19 Jun 2014 06:39:44 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281861A03A8 for ; Thu, 19 Jun 2014 06:39:44 -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 028e2a35.2b13eb2a4940.592282.00-2436.1662675.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 19 Jun 2014 13:39:44 +0000 (UTC) X-MXL-Hash: 53a2e820112d03b4-34138d33ef02bf955e41473373de827d110a8abd 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 208e2a35.0.592038.00-2172.1661961.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 19 Jun 2014 13:39:16 +0000 (UTC) X-MXL-Hash: 53a2e80414fe6947-77a0762e062906af9939b56ead5f167fc7a5a327 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 s5JDdER4012899; Thu, 19 Jun 2014 09:39:14 -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 s5JDd74X012800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 09:39:10 -0400 Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 19 Jun 2014 13:38:59 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.91]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 09:38:58 -0400 From: "STARK, BARBARA H" To: "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Comment on LMAP 06 Suppression Thread-Index: AQHPikvcNpB3Y9Nup0Cfwre7d4ohVZt4o7mAgAAFOwD//8fuIA== Date: Thu, 19 Jun 2014 13:38:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DF7F90@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <53A07119.7030004@centurylink.com> <53A2DCEA.1090500@centurylink.com> In-Reply-To: <53A2DCEA.1090500@centurylink.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.18.187] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DF7F90GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=LbmLHEji c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=sX0W5eZXrF0A:10 a=ofMgfj31e3cA:10 a=cDQzkTEPbkwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=e9qsufxtAAAA:8 a=J_N6KFswAAAA:8 a=S37I6NVsoERBSAVV] X-AnalysisOut: [TlgA:9 a=CjuIK1q_8ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=Pwbduc0PQ3sA:10 a] X-AnalysisOut: [=gz-iTbeLAIb9g1Fc:21 a=kX3FRkxePGGHHw3C:21 a=yMhMjlubAAAA:] X-AnalysisOut: [8 a=SSmOFEACAAAA:8 a=_DIal6B-IhzykIrhRCAA:9 a=gKO2Hq4RSVkA] X-AnalysisOut: [:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 ] X-AnalysisOut: [a=o37hQbMv8cBZBjVd:21 a=H3hQW90p8LH92gom:21 a=Pq0zSWjZCPdI] X-AnalysisOut: [k3Av:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/b6h72e_KqZ8H6pCF9_9iqhhl3dU Subject: Re: [lmap] Comment on LMAP 06 Suppression 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, 19 Jun 2014 13:39:48 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61130DF7F90GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps if the flag were made optional to send but mandatory to implement, = then the choice of default behavior (in absence of flag) for me wouldn't be= worth arguing about. I have no crystal ball regarding which might be more = common, or whether suppression itself will ever get much use (if any). But = "what's the default" is only a problem if the flag is optional to implement= . Sending it when you need it adds very little overhead. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Thursday, June 19, 2014 8:52 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Phil, I'm still not convinced that we should keep the default behavior as is. Pa= rticularly because we can set a flag for a Measurement Task to ignore suppr= ession. The real question is which is the more common case: that a Measurement Tas= k needs to stop completely or that a Measurement Task can continue to compl= etion? People may have differing views on this. My view is that a Suppres= sion is intended to stop the generation of traffic because there is a Netwo= rk emergency of some sort. That implies stopping the Measurement Task imme= diately. If it is not a Network Emergency, then the Controller can simply = update the Measurement Task Schedule to change when a Measurement Task ends= . I also believe that Measurement Tasks that are expected to run to comple= tion can simply have the the ignore Suppression flag set. Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately. Charles On 6/19/2014 6:33 AM, philip.eardley@bt.com w= rote: Charles, I think it's marginally better to keep as-is, so by default suppression doe= sn't impact on-going measurement tasks. Reason is that it's very simple for a MA to stop new Tasks starting (it bar= ely has to do anything), but it may be a bit harder for it to stop on-going= Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c). I guess also it might have a task that essentially runs for ever, such as a= basic connectivity check - but of course this depends how the operator has= defined their tasks and schedules. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: 17 June 2014 17:47 To: 'lmap@ietf.org' Subject: [lmap] Comment on LMAP 06 Suppression A comment regarding ending immediately and completing a Measurement Task in= response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if th= e option is absent needs to be that the Measurement Task will end immediate= ly, because this will be the more common case. I don't think we want to re= quire an option to be set to immediately end all unflagged Measurement Task= s when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 -- 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 --_000_2D09D61DDFA73D4C884805CC7865E61130DF7F90GAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps if the flag= were made optional to send but mandatory to implement, then the choice of = default behavior (in absence of flag) for me wouldn’t be worth arguin= g about. I have no crystal ball regarding which might be more common, or whether suppression itself will ever get mu= ch use (if any). But “what’s the default” is only a probl= em if the flag is optional to implement. Sending it when you need it adds v= ery little overhead.

Barbara<= /span>

 

From: lmap [mailto:lmap-bo= unces@ietf.org] On Behalf Of Charles Cook
Sent: Thursday, June 19, 2014 8:52 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Comment on LMAP 06 Suppression=

 

Phil,

I'm still not convinced that we should keep the default behavior as is.&nbs= p; Particularly because we can set a flag for a Measurement Task to ignore = suppression.

The real question is which is the more common case:  that a Measuremen= t Task needs to stop completely or that a Measurement Task can continue to = completion?  People may have differing views on this.  My view is= that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort.  That i= mplies stopping the Measurement Task immediately.  If it is not a Netw= ork Emergency, then the Controller can simply update the Measurement Task S= chedule to change when a Measurement Task ends.  I also believe that Measurement Tasks that are expected to run= to completion can simply have the the ignore Suppression flag set. 

Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote:

Charles,

 =

I think it= 217;s marginally better to keep as-is, so by default suppression doesn̵= 7;t impact on-going measurement tasks.

Reason is tha= t it’s very simple for a MA to stop new Tasks starting (it barely has= to do anything), but it may be a bit harder for it to stop on-going Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c).

I guess also = it might have a task that essentially runs for ever, such as a basic connec= tivity check – but of course this depends how the operator has defined their tasks and schedules.

 =

Thanks=

phil

 =

 =

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: 'lmap@ietf.org'
Subject: [lmap] Comment on LMAP 06 Suppression

 

A comment regarding ending immediately and completin= g a Measurement Task in response to a Suppress.

 

   o  a demand that the MA ends= its on-going Active Measurement Task(s)
      immediately (and deletes the associated part= ial Measurement
      Result(s)).  If absent, the MA complete= s on-going Measurement
      Tasks.
 

I believe the logic of this option needs to be reversed.  The= default if the option is absent needs to be that the Measurement Task will= end immediately, because this will be the more common case.  I don’t think we want to require an option t= o be set to immediately end all unflagged Measurement Tasks when a simple S= uppress is sent.  Perhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measurem= ent Task(s).

      If absent, the MA ends on-going Mea= surement

      Tasks immediately (and deletes the = associated partial Measurement

      Result(s)).

 

Charles 



-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@century=
link.com



-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
charles.cook2@century=
link.com
--_000_2D09D61DDFA73D4C884805CC7865E61130DF7F90GAALPA1MSGUSRBF_-- From nobody Thu Jun 19 07:11:32 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 049401A036F for ; Thu, 19 Jun 2014 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9akVJVP9Zz-I for ; Thu, 19 Jun 2014 07:11:16 -0700 (PDT) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD291A01EE for ; Thu, 19 Jun 2014 07:11:15 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o142.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id 48fe2a35.2b4089421940.76904.00-585.205261.p01c12o142.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 08:11:16 -0600 (MDT) X-MXL-Hash: 53a2ef8409246409-254a6a0275e3fa5aed3da25d05baeb168f58296e Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p01c12o142.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 96fe2a35.0.76566.00-379.204330.p01c12o142.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 08:10:51 -0600 (MDT) X-MXL-Hash: 53a2ef6b38d4d610-7d62982cb72819722d6b9f8cd3c1dba996f732f2 Received: from ex-mb2.corp.adtran.com ([fe80::7066:bf43:c7f9:c72b]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 09:10:46 -0500 From: KEN KO To: "STARK, BARBARA H" , "charles.cook2@centurylink.com" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Comment on LMAP 06 Suppression Thread-Index: AQHPikvamVUK2w4IuE+fr7P7sJlIkpt4tH2AgAAFOwCAAA0mAP//ssYg Date: Thu, 19 Jun 2014 14:10:45 +0000 Message-ID: References: <53A07119.7030004@centurylink.com> <53A2DCEA.1090500@centurylink.com> <2D09D61DDFA73D4C884805CC7865E61130DF7F90@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DF7F90@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.202] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77757C55Fexmb2corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=UtrtNoAB c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=sX0W5eZXrF0A:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=vRpKd-MsFloA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=J_N6KFswAAAA:8 a=e9qsufxtAAAA:8 a=ITBtWj1emjUUy0cGCFsA] X-AnalysisOut: [:9 a=Ax-d55jLWL_3IfRs:21 a=9CngcxP5UcIpfqWe:21 a=CjuIK1q_8] X-AnalysisOut: [ugA:10 a=fK2py77DiAcA:10 a=pjBFNBMRyLAA:10 a=lZB815dzVvQA:] X-AnalysisOut: [10 a=Pwbduc0PQ3sA:10 a=W1qU_X6G3J8A:10 a=yMhMjlubAAAA:8 a=] X-AnalysisOut: [SSmOFEACAAAA:8 a=mVs83K5Ycwo6Oz0a_90A:9 a=mmzaXhE5OfqtrCct] X-AnalysisOut: [:21 a=hRgIIgsgyQoREIGX:21 a=tQA__RVtS_sfcL_9:21 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061911); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6-zggFEK_P0MkLgO_V2DKcNShZU Subject: Re: [lmap] Comment on LMAP 06 Suppression 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, 19 Jun 2014 14:11:28 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757C55Fexmb2corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Barbara's comment - and in general when we define a flag as o= ptional, we need to specify whether it is optional or mandatory that both v= alues be supported by the function receiving it. Unfortunately, "mandatory to implement" means that MAs need to implement th= e complexity Phil was hoping to avoid whether it is ever used or not. But i= s seems that this complexity will usually scale with the complexity of the = Measurement Task itself - for example, a MA that must clean up state to ter= minate a task would already be tracking state to implement the task. So th= e relative increase in complexity shouldn't be significant in most cases (I= think). Ken From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Thursday, June 19, 2014 9:39 AM To: charles.cook2@centurylink.com; philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Perhaps if the flag were made optional to send but mandatory to implement, = then the choice of default behavior (in absence of flag) for me wouldn't be= worth arguing about. I have no crystal ball regarding which might be more = common, or whether suppression itself will ever get much use (if any). But = "what's the default" is only a problem if the flag is optional to implement= . Sending it when you need it adds very little overhead. Barbara From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Thursday, June 19, 2014 8:52 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Phil, I'm still not convinced that we should keep the default behavior as is. Pa= rticularly because we can set a flag for a Measurement Task to ignore suppr= ession. The real question is which is the more common case: that a Measurement Tas= k needs to stop completely or that a Measurement Task can continue to compl= etion? People may have differing views on this. My view is that a Suppres= sion is intended to stop the generation of traffic because there is a Netwo= rk emergency of some sort. That implies stopping the Measurement Task imme= diately. If it is not a Network Emergency, then the Controller can simply = update the Measurement Task Schedule to change when a Measurement Task ends= . I also believe that Measurement Tasks that are expected to run to comple= tion can simply have the the ignore Suppression flag set. Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately. Charles On 6/19/2014 6:33 AM, philip.eardley@bt.com w= rote: Charles, I think it's marginally better to keep as-is, so by default suppression doe= sn't impact on-going measurement tasks. Reason is that it's very simple for a MA to stop new Tasks starting (it bar= ely has to do anything), but it may be a bit harder for it to stop on-going= Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c). I guess also it might have a task that essentially runs for ever, such as a= basic connectivity check - but of course this depends how the operator has= defined their tasks and schedules. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: 17 June 2014 17:47 To: 'lmap@ietf.org' Subject: [lmap] Comment on LMAP 06 Suppression A comment regarding ending immediately and completing a Measurement Task in= response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if th= e option is absent needs to be that the Measurement Task will end immediate= ly, because this will be the more common case. I don't think we want to re= quire an option to be set to immediately end all unflagged Measurement Task= s when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 -- 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 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757C55Fexmb2corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Barbara&#= 8217;s comment –  and in general when we define a flag as option= al, we need to specify whether it is optional or mandatory that both values= be supported by the function receiving it.

 

Unfortunately, “= mandatory to implement” means that MAs need to implement the complexi= ty Phil was hoping to avoid whether it is ever used or not. But is seems th= at this complexity will usually scale with the complexity of the Measurement Task itself – for example, a MA that must clean u= p state to terminate a task would  already be tracking state to implem= ent the task. So the relative increase in complexity shouldn’t be sig= nificant in most cases (I think).

 

Ken<= /p>

 

From: lma= p [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H
Sent: Thursday, June 19, 2014 9:39 AM
To: charles.cook2@centurylink.com; philip.eardley@bt.com; lmap@ietf.= org
Subject: Re: [lmap] Comment on LMAP 06 Suppression=

 

Perhaps if the flag were made optional to send but mandatory to imp= lement, then the choice of default behavior (in absence of flag) for me wou= ldn’t be worth arguing about. I have no crystal ball regarding which might be more common, or whether suppression = itself will ever get much use (if any). But “what’s the default= ” is only a problem if the flag is optional to implement. Sending it = when you need it adds very little overhead.

Barbara

 

 

Phil,

I'm still not convinced that we should keep the default behavior as is.&nbs= p; Particularly because we can set a flag for a Measurement Task to ignore = suppression.

The real question is which is the more common case:  that a Measuremen= t Task needs to stop completely or that a Measurement Task can continue to = completion?  People may have differing views on this.  My view is= that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort.  That i= mplies stopping the Measurement Task immediately.  If it is not a Netw= ork Emergency, then the Controller can simply update the Measurement Task S= chedule to change when a Measurement Task ends.  I also believe that Measurement Tasks that are expected to run= to completion can simply have the the ignore Suppression flag set. 

Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote:

Charles,

 

I think it’s marginally better to keep as-is, so by def= ault suppression doesn’t impact on-going measurement tasks.

Reason is that it’s very simple for a MA to stop new Ta= sks starting (it barely has to do anything), but it may be a bit harder for it to stop on-going Tasks (at least if it wants to make sure th= ey stop cleanly, perhaps clean up state in the MA, perhaps shut down connec= tions with the remote server etc).

I guess also it might have a task that essentially runs for e= ver, such as a basic connectivity check – but of course this depends how the operator has defined their tasks and schedules.

 

Thanks

phil

 

 

 

A comment regarding endin= g immediately and completing a Measurement Task in response to a Suppress.<= o:p>

 

   o = ; a demand that the MA ends its on-going Active Measurement Task(s)
      immediately (and deletes the associated part= ial Measurement
      Result(s)).  If absent, the MA complete= s on-going Measurement
      Tasks.
 

I believe the logic of this option needs to be reversed.  The default = if the option is absent needs to be that the Measurement Task will end imme= diately, because this will be the more common case.  I don’t thi= nk we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent.  = Perhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measurement Task(= s).

      If absent, the MA ends on-going Measurement<= o:p>

      Tasks immediately (and deletes the associate= d partial Measurement

      Result(s)).

 

Charles 


-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224

Denver, CO  80221


Tel:  303.992.8952  Fax:  92=
5.281.0662


charles.cook2@centurylink.com

 

-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224

Denver, CO  80221


Tel:  303.992.8952  Fax:  92=
5.281.0662


charles.cook2@centurylink.com
--_000_D14B7E40AEBFD54EA3AD964902DD7CB77757C55Fexmb2corpadtran_-- From nobody Thu Jun 19 14:21:55 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 7E5BD1A03F4 for ; Thu, 19 Jun 2014 14:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] 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 gOJ6JsL6-of2 for ; Thu, 19 Jun 2014 14:21:50 -0700 (PDT) Received: from p02c12o143.mxlogic.net (p02c12o143.mxlogic.net [208.65.145.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398081A0316 for ; Thu, 19 Jun 2014 14:21:50 -0700 (PDT) Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o143.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id e6453a35.2abb0020c940.22282.00-576.58145.p02c12o143.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 15:21:50 -0600 (MDT) X-MXL-Hash: 53a3546e0240c2db-7b8b801cfa3f0e2d83c23a6380e6df4e06f6a989 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c12o143.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id a5453a35.0.22041.00-390.57526.p02c12o143.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 15:21:37 -0600 (MDT) X-MXL-Hash: 53a354616b0d0fc5-40df314a152283ff9186d3477b66300c5c23ded2 Received: from ex-mb2.corp.adtran.com ([fe80::7066:bf43:c7f9:c72b]) by ex-hc1.corp.adtran.com ([fe80::a43f:7ea6:7688:37b%13]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 16:21:30 -0500 From: KEN KO To: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= , "'STARK, BARBARA H'" , "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7gAA915FAAKhP3YA== Date: Thu, 19 Jun 2014 21:21:29 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <016501cf8b5e$d57253e0$8056fba0$@com> In-Reply-To: <016501cf8b5e$d57253e0$8056fba0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.202] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DAD5exmb2corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=YqWBRuoX c=1 sm=1 tr=0 a=0XgpNN2/4a34ymu16SVwsQ==] X-AnalysisOut: [:117 a=0XgpNN2/4a34ymu16SVwsQ==:17 a=88wssaZatqEA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=vRpKd-MsFloA:10 a=BLceEmwcHowA:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA:8 a=8A7brI4kjU8C6] X-AnalysisOut: [ETGAX3PRdgeao0=:19 a=MFPoBgoitzMugDe-NJQA:9 a=QEXdDO2ut3YA] X-AnalysisOut: [:10 a=Ce7i_KWWJc8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [dtBtuWMWHyxXoHBA9LgA:9 a=xAUx2tqboc1XOV2x:21 a=gKO2Hq4RSVk] X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061929); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Ryl68mxtoDkaIqlTy0UDyJ_rTqg Subject: Re: [lmap] new version of 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, 19 Jun 2014 21:21:52 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DAD5exmb2corpadtran_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBsYXN0IHNlbnRlbmNlIGFzIGFuIGV4cGxpY2l0IHByb2hpYml0aW9uIGFnYWlu c3QgYSB1c2VyIGRpcmVjdGx5IGluaXRpYXRpbmcgYSBNZWFzdXJlbWVudCBUYXNrLg0KSSBhZ3Jl ZSB3aXRoIEJhcmJhcmEgaW4gYXNraW5nIHRoYXQgaXQgYmUgZGVsZXRlZC4NCg0KDQo1LjYuMS4g IEVuZC11c2VyLWNvbnRyb2xsZWQgbWVhc3VyZW1lbnQgc3lzdGVtDQoNCi4uLg0KDQogICAxLiAg YW4gZW5kLXVzZXIgY291bGQgc29tZWhvdyByZXF1ZXN0IHRoZSBJU1AtIChvciByZWd1bGF0b3It KSBydW4NCg0KICAgICAgIG1lYXN1cmVtZW50IHN5c3RlbSB0byB0ZXN0IGhpcy9oZXIgbGluZS4g IFRoZSBJU1AgKG9yIHJlZ3VsYXRvcikNCg0KICAgICAgIENvbnRyb2xsZXIgd291bGQgdGhlbiBz ZW5kIGFuIEluc3RydWN0aW9uIHRvIHRoZSBNQSBpbiB0aGUgdXN1YWwNCg0KICAgICAgIExNQVAg d2F5LiAgTm90ZSB0aGF0IGEgdXNlciBjYW4ndCBkaXJlY3RseSBpbml0aWF0ZSBhIE1lYXN1cmVt ZW50DQoNCiAgICAgICBUYXNrIG9uIGFuIElTUC0gKG9yIHJlZ3VsYXRvci0pIGNvbnRyb2xsZWQg TUEuDQoNCg0KSW4gYSBjb21tZW50IHRvIHRoZSAtMDQgdmVyc2lvbiBJ4oCZZCBhc2tlZCB0byBo YXZlIHRoZSBsYXN0IHNlbnRlbmNlIGRlbGV0ZWQuIEkgZGlkbuKAmXQgcmVhbGx5IGZvbGxvdyB1 cCBvbiB0aGlzIGFtb25nIGFsbCB0aGUgb3RoZXIgY29tbWVudHMuIEJ1dCBJIHN0aWxsIGZpbmQg dGhpcyB0byBiZSBhbiB1bm5lY2Vzc2FyeSByZXN0cmljdGlvbi4gV2UgaGF2ZSBsb3RzIG9mIGRl dmljZXMgdGhhdCBjb3VsZCBiZSBjb25zaWRlcmVkIHRvIGhhdmUgTUFzIHRoYXQgaGF2ZSBib3Ro IGEg4oCcY29udHJvbGxlcuKAnSBpbnRlcmZhY2UgdGhhdCBhbGxvd3MgZm9yIGFsbCBDb250cm9s bGVyIC0gTUEgYWN0aXZpdGllcywgYW5kIGEgbG9jYWwgdXNlciBpbnRlcmZhY2UgZm9yIGEgbGlt aXRlZCBzZXQgb2YgdXNlci1yZXF1ZXN0ZWQgYWN0aW9ucy4gSSBkb27igJl0IHRoaW5rIHRoaXMg c2hvdWxkIGJlY29tZSBwcm9oaWJpdGVkIGFuZCB0aGF0IHdlIHNob3VsZCBiZSBmb3JjZWQgdG8g cmVtb3ZlIHN1Y2ggYSBsb2NhbCB1c2VyIGludGVyZmFjZSBqdXN0IHRvIG1ha2UgdGhlIE1BIOKA nGNvbXBsaWFudOKAnSB0byB0aGlzIGZyYW1ld29yay4gVGhpcyBpcyBhbiB1bm5lY2Vzc2FyeSBz ZW50ZW5jZS4NClvpgpPngbXojokvTGluZ2xpIERlbmddIEkgZG9u4oCZdCBzZWUgaXQgYXMgYSBy ZXN0cmljdGlvbiBvbiBpbXBsZW1lbnRhdGlvbi4gSXQgb25seSByZWFkcyB0byBtZSB0aGF0IExN QVAgd291bGQgbm90IHN0YW5kYXJkaXplIHRoZSBkaXJlY3QgdXNlci1NQSBpbnRlcmZhY2UuDQoN Cg== --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DAD5exmb2corpadtran_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29Db21tZW50 VGV4dCwgbGkuTXNvQ29tbWVudFRleHQsIGRpdi5Nc29Db21tZW50VGV4dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkNvbW1lbnQgVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1Bs YWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWlu IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7 fQ0Kc3Bhbi5Db21tZW50VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkNvbW1lbnQgVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkNvbW1lbnQg VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K cC5IVE1MLCBsaS5IVE1MLCBkaXYuSFRNTA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7m oLzlvI8iOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCnAuYSwgbGkuYSwgZGl2LmENCgl7bXNvLXN0eWxlLW5h bWU65om55rOo5paH5a2XOw0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmloflrZcgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5paH5a2XIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazrmibnms6jmloflrZc7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpwLmEwLCBsaS5hMCwgZGl2LmEwDQoJe21zby1zdHlsZS1uYW1lOue6r+aW h+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXIwDQoJe21zby1zdHlsZS1uYW1lOiLn uq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r Oue6r+aWh+acrDsNCglmb250LWZhbWlseTpTaW1TdW47fQ0KcC5hMSwgbGkuYTEsIGRpdi5hMQ0K CXttc28tc3R5bGUtbmFtZTrmibnms6jmoYbmlofmnKw7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5DaGFyMQ0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUz NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxT dHlsZTM1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SSByZWFkIHRoZSBsYXN0IHNlbnRlbmNlIGFzIGFuIGV4cGxpY2l0IHByb2hpYml0aW9uIGFnYWlu c3QgYSB1c2VyIGRpcmVjdGx5IGluaXRpYXRpbmcgYSBNZWFzdXJlbWVudCBUYXNrLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBCYXJiYXJhIGluIGFza2luZyB0aGF0IGl0IGJlIGRlbGV0 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjUuNi4xLiZuYnNwOyBFbmQtdXNlci1jb250cm9sbGVkIG1lYXN1cmVtZW50IHN5c3Rl bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgYW4g ZW5kLXVzZXIgY291bGQgc29tZWhvdyByZXF1ZXN0IHRoZSBJU1AtIChvciByZWd1bGF0b3ItKSBy dW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZWFz dXJlbWVudCBzeXN0ZW0gdG8gdGVzdCBoaXMvaGVyIGxpbmUuJm5ic3A7IFRoZSBJU1AgKG9yIHJl Z3VsYXRvcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBDb250cm9sbGVyIHdvdWxkIHRoZW4gc2VuZCBhbiBJbnN0cnVjdGlvbiB0byB0aGUgTUEgaW4g dGhlIHVzdWFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTE1BUCB3YXkuJm5ic3A7IE5vdGUgdGhhdCBhIHVzZXIgY2FuJ3QgZGlyZWN0bHkgaW5pdGlh dGUgYSBNZWFzdXJlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRhc2sgb24gYW4gSVNQLSAob3IgcmVndWxhdG9yLSkgY29udHJvbGxlZCBNQS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SW4gYSBjb21tZW50IHRvIHRoZSAtMDQgdmVy c2lvbiBJ4oCZZCBhc2tlZCB0byBoYXZlIHRoZSBsYXN0IHNlbnRlbmNlIGRlbGV0ZWQuIEkgZGlk buKAmXQgcmVhbGx5IGZvbGxvdyB1cCBvbiB0aGlzIGFtb25nIGFsbCB0aGUgb3RoZXIgY29tbWVu dHMuIEJ1dCBJIHN0aWxsIGZpbmQNCiB0aGlzIHRvIGJlIGFuIHVubmVjZXNzYXJ5IHJlc3RyaWN0 aW9uLiBXZSBoYXZlIGxvdHMgb2YgZGV2aWNlcyB0aGF0IGNvdWxkIGJlIGNvbnNpZGVyZWQgdG8g aGF2ZSBNQXMgdGhhdCBoYXZlIGJvdGggYSDigJxjb250cm9sbGVy4oCdIGludGVyZmFjZSB0aGF0 IGFsbG93cyBmb3IgYWxsIENvbnRyb2xsZXIgLSBNQSBhY3Rpdml0aWVzLCBhbmQgYSBsb2NhbCB1 c2VyIGludGVyZmFjZSBmb3IgYSBsaW1pdGVkIHNldCBvZiB1c2VyLXJlcXVlc3RlZCBhY3Rpb25z Lg0KIEkgZG9u4oCZdCB0aGluayB0aGlzIHNob3VsZCBiZWNvbWUgcHJvaGliaXRlZCBhbmQgdGhh dCB3ZSBzaG91bGQgYmUgZm9yY2VkIHRvIHJlbW92ZSBzdWNoIGEgbG9jYWwgdXNlciBpbnRlcmZh Y2UganVzdCB0byBtYWtlIHRoZSBNQSDigJxjb21wbGlhbnTigJ0gdG8gdGhpcyBmcmFtZXdvcmsu IFRoaXMgaXMgYW4gdW5uZWNlc3Nhcnkgc2VudGVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPls8L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPumCk+eBteiOiTwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPi9MaW5nbGkNCiBEZW5nXSBJIGRvbuKAmXQgc2VlIGl0IGFzIGEgcmVzdHJpY3Rp b24gb24gaW1wbGVtZW50YXRpb24uIEl0IG9ubHkgcmVhZHMgdG8gbWUgdGhhdCBMTUFQIHdvdWxk IG5vdCBzdGFuZGFyZGl6ZSB0aGUgZGlyZWN0IHVzZXItTUEgaW50ZXJmYWNlLjwvc3Bhbj48L2k+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DAD5exmb2corpadtran_-- From nobody Thu Jun 19 14:50:48 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 B044D1A045B for ; Thu, 19 Jun 2014 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 m39e9UeORgfl for ; Thu, 19 Jun 2014 14:50:39 -0700 (PDT) Received: from p01c12o147.mxlogic.net (p01c12o147.mxlogic.net [208.65.145.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10A11A031A for ; Thu, 19 Jun 2014 14:50:38 -0700 (PDT) Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) with ESMTP id f2b53a35.2b65ed60e940.21429.00-524.55842.p01c12o147.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 15:50:39 -0600 (MDT) X-MXL-Hash: 53a35b2f6edcd33b-d48bad9816dbdf6b8c45ef22823c350fd831914a Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p01c12o147.mxlogic.net(mxl_mta-8.0.0-1) over TLS secured channel with ESMTP id 22b53a35.0.21244.00-321.55523.p01c12o147.mxlogic.net (envelope-from ); Thu, 19 Jun 2014 15:50:32 -0600 (MDT) X-MXL-Hash: 53a35b286d45a158-c9a1a9238ab829dcc2548909d313e39beda18fde Received: from ex-mb2.corp.adtran.com ([fe80::7066:bf43:c7f9:c72b]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0181.006; Thu, 19 Jun 2014 16:50:26 -0500 From: KEN KO To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: new version of framework Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwE/LSjg Date: Thu, 19 Jun 2014 21:50:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.202] Content-Type: multipart/alternative; boundary="_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DB37exmb2corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=ZLZZmBLb c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=qZHQZMT3apYA:10 a=vRp] X-AnalysisOut: [Kd-MsFloA:10 a=BLceEmwcHowA:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=YlVTAMxIAAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8] X-AnalysisOut: [ a=P7QkNFfTyYs0A7qIEzgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=W1qU_X6G3J8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=] X-AnalysisOut: [2BctUEAjhDFwSR64GHMA:9 a=4QlMaj9T1Bw-A33N:21 a=gKO2Hq4RSVk] X-AnalysisOut: [A:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014061929); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/9WCJZECZQJW6yFP7hULfbOilxac Subject: Re: [lmap] new version of 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, 19 Jun 2014 21:50:45 -0000 --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DB37exmb2corpadtran_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I've read the new framework document and other than things I've commented o= n separately, the only issues I found were a couple of minor points: - P.17, second bullet in Sec. 5.2.2.1 refers to "Active Measuremen= t Traffic." Delete the word "Active." - P.17, sixth bullet specifies "Active Measurement Task(s)." Sugge= sted rewording: o a demand that the MA ends any on-going Measurement Task(s) tagged for s= uppression immediately (and deletes the associated partial Measurement Resu= lt(s)). If absent, the MA completes on-going Measurement Tasks. Thanks very much for everything. Ken From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: Friday, June 13, 2014 8:39 AM To: lmap@ietf.org Subject: [lmap] new version of framework I just uploaded a new version http://www.ietf.org/id/draft-ietf-lmap-framework-06.txt Barbara, Greg, Ken and others who've made suggestions - Please could you do= a quick check to make sure we got your points properly Thanks Phil --12.6. From -05 to -06 o clarified terminlogy around Measurement Methods and Tasks. Since within a Method there may be several different roles (requester and responder, for instance) o Suppression: there is now the concept of a flag (boolean) which indicates whether a Task is by default gets suppressed or not. The optional suppression message (with list of specific tasks /schedules to suppress) over-rides this flag. o The previous bullet also means there is no need to make a distinction between active and passive Measurement Tasks, so this distinction is removed. I now see a glitch! The final 2 bullets should be replaced by:- o removed Configuration Protocol - Configuration is part of the Instruc= tion and so uses the Control Protocol --_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DB37exmb2corpadtran_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,

 

I’ve read the ne= w framework document and other than things I’ve commented on separate= ly, the only issues I found were a couple of minor points:

 

-&nb= sp;         P.17, second b= ullet in Sec. 5.2.2.1 refers to “Active Measurement Traffic.” D= elete the word “Active.”

-&nb= sp;         P.17, sixth bu= llet specifies “Active Measurement Task(s).” Suggested rewordin= g:

o   a demand that = the MA ends any on-going Measurement Task(s) tagged for suppression immedia= tely (and deletes the associated partial Measurement Result(s)). If absent,= the MA completes on-going Measurement Tasks.

 

Thanks very much for e= verything.

 

Ken<= /p>

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Friday, June 13, 2014 8:39 AM
To: lmap@ietf.org
Subject: [lmap] new version of framework

 

I just uploaded a new version

http:/= /www.ietf.org/id/draft-ietf-lmap-framework-06.txt

 

Barbara, Greg, Ken and others who’ve made suggestions - Please could= you do a quick check to make sure we got your points properly

 

Thanks

Phil

 

--12.6.  From -05 to -06

 

   o  clarified terminlogy arou= nd Measurement Methods and Tasks.  Since

      within a Method= there may be several different roles (requester

      and responder, = for instance)

 

   o  Suppression: there is now= the concept of a flag (boolean) which

      indicates wheth= er a Task is by default gets suppressed or not.

      The optional su= ppression message (with list of specific tasks

      /schedules to s= uppress) over-rides this flag.

 

   o  The previous bullet also = means there is no need to make a

      distinction bet= ween active and passive Measurement Tasks, so this

      distinction is = removed.

 

I now see a glitch! The final 2 bullets should= be replaced by:-

 

   o  removed Configuration Pro= tocol – Configuration is part of the Instruction and so uses the Cont= rol Protocol

 

--_000_D14B7E40AEBFD54EA3AD964902DD7CB77757DB37exmb2corpadtran_-- From nobody Thu Jun 19 19:06: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 234B71A0308 for ; Thu, 19 Jun 2014 19:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] 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 LoW9u_RMnPLe for ; Thu, 19 Jun 2014 19:06:17 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id E30961A016B for ; Thu, 19 Jun 2014 19:06:16 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253a396eaca0-3aca0; Fri, 20 Jun 2014 10:05:31 +0800 (CST) X-RM-TRANSID: 2ee253a396eaca0-3aca0 Received: from cmccPC (unknown[10.2.43.246]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee253a396e94d3-f461c; Fri, 20 Jun 2014 10:05:31 +0800 (CST) X-RM-TRANSID: 2ee253a396e94d3-f461c From: =?utf-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: "'KEN KO'" , "'STARK, BARBARA H'" , , References: <2D09D61DDFA73D4C884805CC7865E61130DF7CAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <016501cf8b5e$d57253e0$8056fba0$@com> In-Reply-To: Date: Fri, 20 Jun 2014 10:06:07 +0800 Message-ID: <023101cf8c2c$331c3510$99549f30$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0232_01CF8C6F.413F7510" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+HA9K9h5glTitqRROfTGRMo1GgvwEGgN7gAA915FAAKhP3YAAKCZMg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Nuv2ih5XAQn2_-jvxd9j8RvEuIE Subject: Re: [lmap] new version of 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: Fri, 20 Jun 2014 02:06:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0232_01CF8C6F.413F7510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of KEN KO Sent: Friday, June 20, 2014 5:21 AM To: =E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng; 'STARK, BARBARA H'; = philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] new version of framework =20 I read the last sentence as an explicit prohibition against a user = directly initiating a Measurement Task.=20 [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] In that case, I support the = deletion too. I agree with Barbara in asking that it be deleted. =20 5.6.1. End-user-controlled measurement system ... 1. an end-user could somehow request the ISP- (or regulator-) run measurement system to test his/her line. The ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way. Note that a user can't directly initiate a Measurement Task on an ISP- (or regulator-) controlled MA. =20 In a comment to the -04 version I=E2=80=99d asked to have the last = sentence deleted. I didn=E2=80=99t really follow up on this among all = the other comments. But I still find this to be an unnecessary = restriction. We have lots of devices that could be considered to have = MAs that have both a =E2=80=9Ccontroller=E2=80=9D interface that allows = for all Controller - MA activities, and a local user interface for a = limited set of user-requested actions. I don=E2=80=99t think this should = become prohibited and that we should be forced to remove such a local = user interface just to make the MA =E2=80=9Ccompliant=E2=80=9D to this = framework. This is an unnecessary sentence. [=E9=82=93=E7=81=B5=E8=8E=89/Lingli Deng] I don=E2=80=99t see it as a = restriction on implementation. It only reads to me that LMAP would not = standardize the direct user-MA interface. =20 ------=_NextPart_000_0232_01CF8C6F.413F7510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

From:= lmap = [mailto:lmap-bounces@ietf.org] On Behalf Of KEN = KO
Sent: Friday, June 20, 2014 5:21 AM
To: = =E9=82=93=E7=81= =B5=E8=8E=89/Lingli = Deng; 'STARK, BARBARA H'; philip.eardley@bt.com; = lmap@ietf.org
Subject: Re: [lmap] new version of = framework

 

I read the last sentence as an = explicit prohibition against a user directly initiating a Measurement = Task.

[=E9= =82=93=E7=81=B5=E8=8E=89/Lingli Deng] In that case, I = support the deletion too.

I agree = with Barbara in asking that it be deleted.

 

5.6.1.  End-user-controlled measurement = system

...

   = 1.  an end-user could somehow request the ISP- (or regulator-) = run

       measurement system to test = his/her line.  The ISP (or regulator)

       Controller would then send an = Instruction to the MA in the usual

       LMAP way.  Note that a = user can't directly initiate a Measurement

       Task on an ISP- (or = regulator-) controlled MA.

 

In a comment to the -04 version I=E2=80=99d = asked to have the last sentence deleted. I didn=E2=80=99t really follow = up on this among all the other comments. But I still find this to be an = unnecessary restriction. We have lots of devices that could be = considered to have MAs that have both a =E2=80=9Ccontroller=E2=80=9D = interface that allows for all Controller - MA activities, and a local = user interface for a limited set of user-requested actions. I = don=E2=80=99t think this should become prohibited and that we should be = forced to remove such a local user interface just to make the MA = =E2=80=9Ccompliant=E2=80=9D to this framework. This is an unnecessary = sentence.

[=E9= =82=93=E7=81=B5=E8=8E=89/Lingli Deng] I don=E2=80=99t = see it as a restriction on implementation. It only reads to me that LMAP = would not standardize the direct user-MA interface.

 

------=_NextPart_000_0232_01CF8C6F.413F7510-- From nobody Fri Jun 20 07: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 844851A03C1 for ; Fri, 20 Jun 2014 07:21:19 -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, HTML_MESSAGE=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 a6lf-zt2MWoc for ; Fri, 20 Jun 2014 07:21:16 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0409F1A0362 for ; Fri, 20 Jun 2014 07:21:15 -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 s5KEL4Tg000417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2014 08:21:05 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 69E9A1E0093; Fri, 20 Jun 2014 08:20:54 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 139391E008C; Fri, 20 Jun 2014 08:20:54 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s5KEKr3T021999; Fri, 20 Jun 2014 08:20:53 -0600 (MDT) Received: from [10.188.201.149] (x1069818.dhcp.intranet [10.188.201.149]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id s5KEKpHw021909; Fri, 20 Jun 2014 08:20:51 -0600 (MDT) Message-ID: <53A44342.80206@centurylink.com> Date: Fri, 20 Jun 2014 08:20:50 -0600 From: Charles Cook User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <53A07119.7030004@centurylink.com> <53A2DCEA.1090500@centurylink.com> <2845723087023D4CB5114223779FA9C801896A8087@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C801896A8087@njfpsrvexg8.research.att.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020101050700040704080107" X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/3m0mOd7XaMBr7kiFqor6yjshpgY Subject: Re: [lmap] Comment on LMAP 06 Suppression 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: Fri, 20 Jun 2014 14:21:19 -0000 This is a multi-part message in MIME format. --------------020101050700040704080107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Al, I don't think I recognized a Suppression "Panic-button" capability in the draft that would shut everything down (except of course those Measurement Tasks with the Ignore Suppression flag set). So additional clarification may indeed help me out. Charles On 6/19/2014 7:39 AM, MORTON, ALFRED C (AL) wrote: > > Charles, > > > > The currently-defined Suppression has a "Panic-button" capability > > which satisfies your case of a Network Emergency. Perhaps we could > > make this more clear. > > > > If we cast the message starting from Panic/Full-Stop, it seems more > > unexpected to add options for only on-going tasks, or only certain tasks, > > or start times, etc. IMO, it's called Suppression now to allow for > > different degrees of measurement deletion, all the way up to full stop. > > > > It also seems tom that it's easier to resume (Unsuppress) the measurement > > schedule from the current definition of Suppression. Long-term or > On-going > > measurement tasks would probably need to be re-scheduled after > > a Panic/Full-Stop is withdrawn. > > > > Al > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Charles Cook > *Sent:* Thursday, June 19, 2014 8:52 AM > *To:* philip.eardley@bt.com; lmap@ietf.org > *Subject:* Re: [lmap] Comment on LMAP 06 Suppression > > > > Phil, > > I'm still not convinced that we should keep the default behavior as > is. Particularly because we can set a flag for a Measurement Task to > ignore suppression. > > The real question is which is the more common case: that a > Measurement Task needs to stop completely or that a Measurement Task > can continue to completion? People may have differing views on this. > My view is that a Suppression is intended to stop the generation of > traffic because there is a Network emergency of some sort. That > implies stopping the Measurement Task immediately. If it is not a > Network Emergency, then the Controller can simply update the > Measurement Task Schedule to change when a Measurement Task ends. I > also believe that Measurement Tasks that are expected to run to > completion can simply have the the ignore Suppression flag set. > > Consequently, I believe the default response should be reversed so > that an optional parameter does not need to be set in order to cause a > Measurement Task to cease immediately. > > Charles > > On 6/19/2014 6:33 AM, philip.eardley@bt.com > wrote: > > Charles, > > > > I think it's marginally better to keep as-is, so by default > suppression doesn't impact on-going measurement tasks. > > Reason is that it's very simple for a MA to stop new Tasks > starting (it barely has to do anything), but it may be a bit > harder for it to stop on-going Tasks (at least if it wants to make > sure they stop cleanly, perhaps clean up state in the MA, perhaps > shut down connections with the remote server etc). > > I guess also it might have a task that essentially runs for ever, > such as a basic connectivity check -- but of course this depends > how the operator has defined their tasks and schedules. > > > > Thanks > > phil > > > > > > *From:*lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Charles Cook > *Sent:* 17 June 2014 17:47 > *To:* 'lmap@ietf.org ' > *Subject:* [lmap] Comment on LMAP 06 Suppression > > > > A comment regarding ending immediately and completing a > Measurement Task in response to a Suppress. > > > > o a demand that the MA ends its on-going Active Measurement > Task(s) > immediately (and deletes the associated partial Measurement > Result(s)). If absent, the MA completes on-going Measurement > Tasks. > > > I believe the logic of this option needs to be reversed. The > default if the option is absent needs to be that the Measurement > Task will end immediately, because this will be the more common > case. I don't think we want to require an option to be set to > immediately end all unflagged Measurement Tasks when a simple > Suppress is sent. Perhaps something like this would work. > > > > o a demand that the MA competes its on-going Active Measurement > Task(s). > > If absent, the MA ends on-going Measurement > > Tasks immediately (and deletes the associated partial > Measurement > > Result(s)). > > > > Charles > > > > -- > > > > 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 > > > > -- > > 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 -- 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 --------------020101050700040704080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Al,

I don't think I recognized a Suppression "Panic-button" capability in the draft that would shut everything down (except of course those Measurement Tasks with the Ignore Suppression flag set).  So additional clarification may indeed help me out.

Charles

On 6/19/2014 7:39 AM, MORTON, ALFRED C (AL) wrote:

Charles,

 

The currently-defined Suppression has a "Panic-button" capability

which satisfies your case of a Network Emergency. Perhaps we could

make this more clear.

 

If we cast the message starting from Panic/Full-Stop, it seems more

unexpected to add options for only on-going tasks, or only certain tasks,

or start times, etc. IMO, it's called Suppression now to allow for

different degrees of measurement deletion, all the way up to full stop.

 

It also seems tom that it's easier to resume (Unsuppress) the measurement

schedule from the current definition of Suppression. Long-term or On-going

measurement tasks would probably need to be re-scheduled after

a Panic/Full-Stop is withdrawn.

 

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook
Sent: Thursday, June 19, 2014 8:52 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Comment on LMAP 06 Suppression

 

Phil,

I'm still not convinced that we should keep the default behavior as is.  Particularly because we can set a flag for a Measurement Task to ignore suppression.

The real question is which is the more common case:  that a Measurement Task needs to stop completely or that a Measurement Task can continue to completion?  People may have differing views on this.  My view is that a Suppression is intended to stop the generation of traffic because there is a Network emergency of some sort.  That implies stopping the Measurement Task immediately.  If it is not a Network Emergency, then the Controller can simply update the Measurement Task Schedule to change when a Measurement Task ends.  I also believe that Measurement Tasks that are expected to run to completion can simply have the the ignore Suppression flag set. 

Consequently, I believe the default response should be reversed so that an optional parameter does not need to be set in order to cause a Measurement Task to cease immediately.

Charles

On 6/19/2014 6:33 AM, philip.eardley@bt.com wrote:

Charles,

 

I think it’s marginally better to keep as-is, so by default suppression doesn’t impact on-going measurement tasks.

Reason is that it’s very simple for a MA to stop new Tasks starting (it barely has to do anything), but it may be a bit harder for it to stop on-going Tasks (at least if it wants to make sure they stop cleanly, perhaps clean up state in the MA, perhaps shut down connections with the remote server etc).

I guess also it might have a task that essentially runs for ever, such as a basic connectivity check – but of course this depends how the operator has defined their tasks and schedules.

 

Thanks

phil

 

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: 'lmap@ietf.org'
Subject: [lmap] Comment on LMAP 06 Suppression

 

A comment regarding ending immediately and completing a Measurement Task in response to a Suppress.

 

   o  a demand that the MA ends its on-going Active Measurement Task(s)
      immediately (and deletes the associated partial Measurement
      Result(s)).  If absent, the MA completes on-going Measurement
      Tasks.
 

I believe the logic of this option needs to be reversed.  The default if the option is absent needs to be that the Measurement Task will end immediately, because this will be the more common case.  I don’t think we want to require an option to be set to immediately end all unflagged Measurement Tasks when a simple Suppress is sent.  Perhaps something like this would work.

 

o  a demand that the MA competes its on-going Active Measurement Task(s).

      If absent, the MA ends on-going Measurement

      Tasks immediately (and deletes the associated partial Measurement

      Result(s)).

 

Charles 



-- 
 
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



-- 
 
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

-- 

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
--------------020101050700040704080107-- From nobody Mon Jun 23 03:17: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 2B4271B28CD for ; Mon, 23 Jun 2014 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRLdELrk1pVe for ; Mon, 23 Jun 2014 03:17:20 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4471B28FC for ; Mon, 23 Jun 2014 03:17:19 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 23 Jun 2014 11:13:22 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.112]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 23 Jun 2014 11:17:17 +0100 From: To: , , Date: Mon, 23 Jun 2014 11:17:16 +0100 Thread-Topic: [lmap] Comment on LMAP 06 Suppression Thread-Index: Ac+MkuS9iBCGfb2IQM2zWZiMdS4p1QCMq0Cg Message-ID: References: <53A07119.7030004@centurylink.com> <53A2DCEA.1090500@centurylink.com> <2845723087023D4CB5114223779FA9C801896A8087@njfpsrvexg8.research.att.com> <53A44342.80206@centurylink.com> In-Reply-To: <53A44342.80206@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: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D41190155C7EMV67UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Y0IuqMlvqMxVHmPgojBIMXsnm0I Subject: Re: [lmap] Comment on LMAP 06 Suppression 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, 23 Jun 2014 10:17:26 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D41190155C7EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On mandatory to implement and optional to send - yes. I think this is impl= ied by the current text "The Suppression information may include any of the= following optional fields:" In general I don't like optional-to-implement aspects, as it hinders intero= perability - and I'm not expecting the lmap protocol to be hugely complex. I have adjusted the bullet so it says: << a demand that the MA ends its on-going Measurement Task(s) immediately (= and deletes the associated partial Measurement Result(s)). This could be us= eful in the case of a network emergency so that the operator can eliminate = all inessential traffic as rapidly as possible. If absent, the MA completes= on-going Measurement Tasks.>> If I read the discussion correctly, this is the consensus. Bet wishes phil From: Charles Cook [mailto:charles.cook2@centurylink.com] Sent: 20 June 2014 15:21 To: MORTON, ALFRED C (AL); Eardley,PL,Philip,TUB8 R; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Al, I don't think I recognized a Suppression "Panic-button" capability in the d= raft that would shut everything down (except of course those Measurement Ta= sks with the Ignore Suppression flag set). So additional clarification may= indeed help me out. Charles On 6/19/2014 7:39 AM, MORTON, ALFRED C (AL) wrote: Charles, The currently-defined Suppression has a "Panic-button" capability which satisfies your case of a Network Emergency. Perhaps we could make this more clear. If we cast the message starting from Panic/Full-Stop, it seems more unexpected to add options for only on-going tasks, or only certain tasks, or start times, etc. IMO, it's called Suppression now to allow for different degrees of measurement deletion, all the way up to full stop. It also seems tom that it's easier to resume (Unsuppress) the measurement schedule from the current definition of Suppression. Long-term or On-going measurement tasks would probably need to be re-scheduled after a Panic/Full-Stop is withdrawn. Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: Thursday, June 19, 2014 8:52 AM To: philip.eardley@bt.com; lmap@ietf.org Subject: Re: [lmap] Comment on LMAP 06 Suppression Phil, I'm still not convinced that we should keep the default behavior as is. Pa= rticularly because we can set a flag for a Measurement Task to ignore suppr= ession. The real question is which is the more common case: that a Measurement Tas= k needs to stop completely or that a Measurement Task can continue to compl= etion? People may have differing views on this. My view is that a Suppres= sion is intended to stop the generation of traffic because there is a Netwo= rk emergency of some sort. That implies stopping the Measurement Task imme= diately. If it is not a Network Emergency, then the Controller can simply = update the Measurement Task Schedule to change when a Measurement Task ends= . I also believe that Measurement Tasks that are expected to run to comple= tion can simply have the the ignore Suppression flag set. Consequently, I believe the default response should be reversed so that an = optional parameter does not need to be set in order to cause a Measurement = Task to cease immediately. Charles On 6/19/2014 6:33 AM, philip.eardley@bt.com w= rote: Charles, I think it's marginally better to keep as-is, so by default suppression doe= sn't impact on-going measurement tasks. Reason is that it's very simple for a MA to stop new Tasks starting (it bar= ely has to do anything), but it may be a bit harder for it to stop on-going= Tasks (at least if it wants to make sure they stop cleanly, perhaps clean = up state in the MA, perhaps shut down connections with the remote server et= c). I guess also it might have a task that essentially runs for ever, such as a= basic connectivity check - but of course this depends how the operator has= defined their tasks and schedules. Thanks phil From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook Sent: 17 June 2014 17:47 To: 'lmap@ietf.org' Subject: [lmap] Comment on LMAP 06 Suppression A comment regarding ending immediately and completing a Measurement Task in= response to a Suppress. o a demand that the MA ends its on-going Active Measurement Task(s) immediately (and deletes the associated partial Measurement Result(s)). If absent, the MA completes on-going Measurement Tasks. I believe the logic of this option needs to be reversed. The default if th= e option is absent needs to be that the Measurement Task will end immediate= ly, because this will be the more common case. I don't think we want to re= quire an option to be set to immediately end all unflagged Measurement Task= s when a simple Suppress is sent. Perhaps something like this would work. o a demand that the MA competes its on-going Active Measurement Task(s). If absent, the MA ends on-going Measurement Tasks immediately (and deletes the associated partial Measurement Result(s)). Charles -- 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 -- 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 -- 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 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D41190155C7EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
On mandatory to implement and optional to send –=
 yes.  I think this is implied by the current text “The Suppression information may inclu=
de any of the following optional fields:”
In general I don’t like optional-to-implement aspects, as it hin= ders interoperability – and I’m not expecting the lmap protocol= to be hugely complex.

 

I have adjusted the bullet so it says:

<< a demand th= at the MA ends its on-going Measurement Task(s) immediately (and deletes th= e associated partial Measurement Result(s)). This could be useful in the ca= se of a network emergency so that the operator can eliminate all inessentia= l traffic as rapidly as possible. If absent, the MA completes on-going Meas= urement Tasks.>>

If I read the discussion correctly, this is the consensus.

 

Bet wishes=

phil

 

From: Charles Cook [mailto:cha= rles.cook2@centurylink.com]
Sent: 20 June 2014 15:21
To: MORTON, ALFRED C (AL); Eardley,PL,Philip,TUB8 R; lmap@ietf.org
Sub= ject: Re: [lmap] Comment on LMAP 06 Suppression

 

Al,

I don't think I recognized a Suppre= ssion "Panic-button" capability in the draft that would shut ever= ything down (except of course those Measurement Tasks with the Ignore Suppr= ession flag set).  So additional clarification may indeed help me out.=

Charles

On 6/19/2014 7:39 A= M, MORTON, ALFRED C (AL) wrote:

Charles,

 

The currently-defined Suppression has a "Panic-button&quo= t; capability

which satisfies your case of a Network Emergency. Perhaps we could<= /span>

make t= his more clear.

 

If we cast the message starting from Panic/Full-Stop, it seems m= ore

un= expected to add options for only on-going tasks, or only certain tasks,

or start = times, etc. IMO, it's called Suppression now to allow for

different degrees of m= easurement deletion, all the way up to full stop.

 

It also seems tom that it's ea= sier to resume (Unsuppress) the measurement

schedule from the current definitio= n of Suppression. Long-term or On-going

measurement tasks would probably need to= be re-scheduled after

a Panic/Full-Stop is withdrawn.

 

Al

 

From: lmap [= mailto:lmap-bounces@ietf.org] On Behalf Of Charles Cook
Se= nt: Thursday, June 19, 2014 8:52 AM
To: philip.eardley@bt.com; lmap@ietf.org
Subject: Re: [lmap] Comment on LMAP 06 Sup= pression

 <= /o:p>

Phil,

I= 'm still not convinced that we should keep the default behavior as is. = ; Particularly because we can set a flag for a Measurement Task to ignore s= uppression.

The real question is which is the more common case: = ; that a Measurement Task needs to stop completely or that a Measurement Ta= sk can continue to completion?  People may have differing views on thi= s.  My view is that a Suppression is intended to stop the generation o= f traffic because there is a Network emergency of some sort.  That imp= lies stopping the Measurement Task immediately.  If it is not a Networ= k Emergency, then the Controller can simply update the Measurement Task Sch= edule to change when a Measurement Task ends.  I also believe that Mea= surement Tasks that are expected to run to completion can simply have the t= he ignore Suppression flag set. 

Consequently, I believe the d= efault response should be reversed so that an optional parameter does not n= eed to be set in order to cause a Measurement Task to cease immediately.
Charles


On 6/19/20= 14 6:33 AM, philip.eardley@bt.com<= /a> wrote:

Charles,=

 <= /p>

I think it’s marginally be= tter to keep as-is, so by default suppression doesn’t impact on-going= measurement tasks.

Reason is that it’s very simple for a MA to stop new Tasks st= arting (it barely has to do anything), but it may be a bit harder for it to= stop on-going Tasks (at least if it wants to make sure they stop cleanly, = perhaps clean up state in the MA, perhaps shut down connections with the re= mote server etc).

I guess also it might have a task that essentially runs for ever, such = as a basic connectivity check – but of course this depends how the op= erator has defined their tasks and schedules.

 

Thanks

<= span style=3D'font-size:12.0pt;line-height:115%;font-family:"Arial","sans-s= erif";color:blue'>phil

 

From: lmap [mailto:lmap-bounces@ietf.org] On= Behalf Of Charles Cook
Sent: 17 June 2014 17:47
To: 'lmap@ietf.org'
Subject: [= lmap] Comment on LMAP 06 Suppression

 

A comment regardi= ng ending immediately and completing a Measurement Task in response to a Su= ppress.

 

<= span style=3D'font-family:"Courier New , serif , serif","serif"'> &nbs= p; o  a demand that the MA ends its on-going Active Measurement Task(s= )
      immediately (and deletes the associated= partial Measurement
      Result(s)).  If= absent, the MA completes on-going Measurement
    &= nbsp; Tasks.
 

I believe the logic of t= his option needs to be reversed.  The default if the option is absent = needs to be that the Measurement Task will end immediately, because this wi= ll be the more common case.  I don’t think we want to require an= option to be set to immediately end all unflagged Measurement Tasks when a= simple Suppress is sent.  Perhaps something like this would work.

 

o  a demand that the MA = competes its on-going Active Measurement Task(s).

&nbs= p;     If absent, the MA ends on-going Measurement=

      Tasks immediately (and dele= tes the associated partial Measurement

  &nb= sp;   Result(s)).

 

Charles 




-- 
 
=
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
<= pre>Denver, CO  80221
Tel:  303.992.8952&nbs=
p; Fax:  925.281.0662
charles.cook2@centurylink.com


<= br>

-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224<=
/o:p>
Denver, CO  80221
Tel:  303.=
992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com

<= br>

-- 
 
Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224<=
/o:p>
Denver, CO  80221
Tel:  303.=
992.8952  Fax:  925.281.0662
charles.cook2@centurylink.com
= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D41190155C7EMV67UKRDdoma_-- From nobody Mon Jun 23 14:38:47 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 BCF7F1B2CEC for ; Mon, 23 Jun 2014 14:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 gtlN5DXNIzxQ for ; Mon, 23 Jun 2014 14:38:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2668E1B2C45 for ; Mon, 23 Jun 2014 14:38:43 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5NLcfGx002123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jun 2014 16:38:41 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5NLcfRv001544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 17:38:41 -0400 Received: from US70TWXCHMBA08.zam.alcatel-lucent.com ([169.254.2.45]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 23 Jun 2014 17:38:41 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: LMAP Information model: Calendar schedules and timezones Thread-Index: Ac+PKt77zr1NBQUETbWuHypUl1ndKw== Date: Mon, 23 Jun 2014 21:38:40 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.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_9966516C6EB5FC4381E05BF80AA55F7734EF4933US70TWXCHMBA08z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/PfHQ2coClzIQQLNojt6Sb2dEl_4 Subject: [lmap] LMAP Information model: Calendar schedules and timezones 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, 23 Jun 2014 21:38:45 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734EF4933US70TWXCHMBA08z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, I presented the calendar object to the BBF and suggested a timezone offset = parameter as defined in LMAP Information model. object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-weekdays<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; What the BBHome group noted was that the datetime object type already has a= timezone element associated with the type. So the suggestion is that that the schedule should utilize the timezone of = the start and end time parameters and that we constrain these parameters to= use the same timezone. This should solve the problem without the need for = a timezone offset parameter. Thoughts? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F7734EF4933US70TWXCHMBA08z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

 

I presented the calendar object to the BBF a= nd suggested a timezone offset parameter as defined in LMAP Information mod= el.

 

object {

[datetime ma-calendar-start;] // default: im= mediate

[datetime ma-calendar-end;] // default: inde= finite

[int ma-calendar-months<0..*>;] // def= ault: 1-12

[days ma-calendar-weekdays<0..*>;] // = default: all

[int ma-calendar-hours<0..*>;] // defa= ult: 0-23

[int ma-calendar-minutes<0..*>;] // de= fault: 0-59

[int ma-calendar-seconds<0..*>;] // de= fault: 0-59

[int ma-calendar-timezone-offset;]

// default: system timezone offset

} ma-calendar-obj;

 

 

What the BBHome group noted was that the datetime o= bject type already has a timezone element associated with the type.

 

So the suggestion is that that the schedule should = utilize the timezone of the start and end time parameters and that we const= rain these parameters to use the same timezone. This should solve the problem without the need for a timezone offset parameter.

 

Thoughts?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F7734EF4933US70TWXCHMBA08z_-- From nobody Mon Jun 23 14:40: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 121BA1B2C45 for ; Mon, 23 Jun 2014 14:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 IYeXPTjA9161 for ; Mon, 23 Jun 2014 14:40:53 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 53E501B2CEC for ; Mon, 23 Jun 2014 14:40:53 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 1C1071A072A; Mon, 23 Jun 2014 23:40:51 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_053119CC-FF62-4DED-B4CE-B0206FA9548F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> Date: Mon, 23 Jun 2014 23:40:51 +0200 Message-Id: <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> To: "Carey, Timothy (Timothy)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_wANQuLIMKB4cshKq4RnfzPn-VM Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 23 Jun 2014 21:40:56 -0000 --Apple-Mail=_053119CC-FF62-4DED-B4CE-B0206FA9548F Content-Type: multipart/alternative; boundary="Apple-Mail=_2D0581EB-2F78-4DCD-856C-54BD46A50F61" --Apple-Mail=_2D0581EB-2F78-4DCD-856C-54BD46A50F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi, Tim, all, Is there any reason not to simply mandate the use of UTC here? Cheers, Brian On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) = wrote: > Team, > =20 > =20 > I presented the calendar object to the BBF and suggested a timezone = offset parameter as defined in LMAP Information model. > =20 > object { > [datetime ma-calendar-start;] // default: immediate > [datetime ma-calendar-end;] // default: indefinite > [int ma-calendar-months<0..*>;] // default: 1-12 > [days ma-calendar-weekdays<0..*>;] // default: all > [int ma-calendar-hours<0..*>;] // default: 0-23 > [int ma-calendar-minutes<0..*>;] // default: 0-59 > [int ma-calendar-seconds<0..*>;] // default: 0-59 > [int ma-calendar-timezone-offset;] > // default: system timezone offset > } ma-calendar-obj; > =20 > =20 > What the BBHome group noted was that the datetime object type already = has a timezone element associated with the type. > =20 > So the suggestion is that that the schedule should utilize the = timezone of the start and end time parameters and that we constrain = these parameters to use the same timezone. This should solve the problem = without the need for a timezone offset parameter. > =20 > Thoughts? > =20 > Thanks, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_2D0581EB-2F78-4DCD-856C-54BD46A50F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hi, = Tim, all,

Is there any reason not to simply mandate = the use of UTC = here?

Cheers,

Brian

On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) = <timothy.carey@alcatel-luc= ent.com> wrote:

Team,
 
 
I presented the = calendar object to the BBF and suggested a timezone offset parameter as = defined in LMAP Information model.
 
object = {
[datetime = ma-calendar-start;] // default: immediate
[datetime ma-calendar-end;] // default: = indefinite
[int = ma-calendar-months<0..*>;] // default: = 1-12
[days = ma-calendar-weekdays<0..*>;] // default: = all
[int = ma-calendar-hours<0..*>;] // default: = 0-23
[int = ma-calendar-minutes<0..*>;] // default: = 0-59
[int = ma-calendar-seconds<0..*>;] // default: = 0-59
[int = ma-calendar-timezone-offset;]
// = default: system timezone offset
} ma-calendar-obj;
 
 
What the BBHome group = noted was that the datetime object type already has a timezone element = associated with the type.
 
So the suggestion is = that that the schedule should utilize the timezone of the start and end = time parameters and that we constrain these parameters to use the same = timezone. This should solve the problem without the need for a timezone = offset parameter.
 
Thoughts?
 
Thanks,
Tim
____________________________= ___________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap

= --Apple-Mail=_2D0581EB-2F78-4DCD-856C-54BD46A50F61-- --Apple-Mail=_053119CC-FF62-4DED-B4CE-B0206FA9548F 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 iQEcBAEBCgAGBQJTqJ7jAAoJENt3nsOmbNJc4eQH/1wPwqqvG/SX40sgJZf0dP37 A4peoIftkyBlCujQgPGbB6b69MzYcT/DvL5BEFfPHSnRUXP8IzIopgOkPwZ2oWLl 0Gch2qovovIq/YBM5hGEB0e8qPbxCFfnpYf3SbZ4NPdZhc3Pb3bnPIO0ncAtmJS6 cSSQBtYmR6+DExKC6VbwIy3HxUxvcOIU+yWDvuz8M3J+RAVsA97rqnr3Kf3tfdn0 UwpE+2ncYwypYHRo0WiJss3xhX1k5wAgSBjc5TUBRF0FOqf8odXPfM3L9sGf+/Ks BqVgC6ej4iuD0B50vTZkFXQAK+TCcoaRVTe+VAGggxbTzk9+GHed+yuRI/QV2Ps= =8/us -----END PGP SIGNATURE----- --Apple-Mail=_053119CC-FF62-4DED-B4CE-B0206FA9548F-- From nobody Mon Jun 23 15:18: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 9A1C01B2D2E for ; Mon, 23 Jun 2014 15:18:37 -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 MhWkCOg0S1Ta for ; Mon, 23 Jun 2014 15:18:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB7A1B2D27 for ; Mon, 23 Jun 2014 15:18:29 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5NMIIT8007793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jun 2014 17:18:18 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s5NMIIvJ014804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jun 2014 18:18:18 -0400 Received: from US70TWXCHMBA08.zam.alcatel-lucent.com ([169.254.2.45]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 23 Jun 2014 18:18:17 -0400 From: "Carey, Timothy (Timothy)" To: Brian Trammell Thread-Topic: [lmap] LMAP Information model: Calendar schedules and timezones Thread-Index: Ac+PKt77zr1NBQUETbWuHypUl1ndKwAInWGAAAhPBDA= Date: Mon, 23 Jun 2014 22:18:17 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> In-Reply-To: <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> 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_9966516C6EB5FC4381E05BF80AA55F7734EF4B11US70TWXCHMBA08z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/l_krPUlPblsthv4vONH9_S25Vo4 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 23 Jun 2014 22:18:37 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F7734EF4B11US70TWXCHMBA08z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, There was a request for a time to be used as the local timezone of host - w= hen a timezone is not supplied. Calendar Timing is also required to perform measurements at meaningful instances in relation to network usage (e.g., at peak times). If the optional timezone offset is not supplied then local system time is assumed. This is essential in some use cases to ensure consistent peak-time measurements as well as supporting MA devices that may be in an unknown timezone or roam between different timezones (but know their own timezone information such as through the mobile network). So an ISO 8601 dateTime already has a timezone - so we should use these if = provided and we should constrain the start and end to use the same time zon= e. Unfortunately I think the ISO 8601 datetime states that an undocumented tim= ezone is undetermined. This is what the BBF uses for a data type. We could just state that an undocumented timezone is default timezone of th= e system - that should work as well. BR, Tim From: Brian Trammell [mailto:ietf@trammell.ch] Sent: Monday, June 23, 2014 3:41 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezone= s hi, Tim, all, Is there any reason not to simply mandate the use of UTC here? Cheers, Brian On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) > wrote: Team, I presented the calendar object to the BBF and suggested a timezone offset = parameter as defined in LMAP Information model. object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-weekdays<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; What the BBHome group noted was that the datetime object type already has a= timezone element associated with the type. So the suggestion is that that the schedule should utilize the timezone of = the start and end time parameters and that we constrain these parameters to= use the same timezone. This should solve the problem without the need for = a timezone offset parameter. Thoughts? Thanks, Tim _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_9966516C6EB5FC4381E05BF80AA55F7734EF4B11US70TWXCHMBA08z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 

There was a request = for a time to be used as the local timezone of host – when a timezone= is not supplied.

 

Calendar Timing is also required to perform = measurements at

meaningful instances in relation to network = usage (e.g., at peak

times). If the optional timezone offset is n= ot supplied then local

system time is assumed. This is essential in= some use cases to

ensure consistent peak-time measurements as = well as supporting MA

devices that may be in an unknown timezone o= r roam between different

timezones (but know their own timezone infor= mation such as through

the mobile network).

 

So an ISO 8601 dateT= ime already has a timezone – so we should use these if provided and w= e should constrain the start and end to use the same time zone.<= /span>

 

Unfortunately I thin= k the ISO 8601 datetime states that an undocumented timezone is undetermine= d. This is what the BBF uses for a data type.

 

We could just state = that an undocumented timezone is default timezone of the system – tha= t should work as well.

 

BR,

Tim

 

From: Brian Tr= ammell [mailto:ietf@trammell.ch]
Sent: Monday, June 23, 2014 3:41 PM
To: Carey, Timothy (Timothy)
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Information model: Calendar schedules and t= imezones

 

hi, Tim, all,

 

Is there any reason not to simply mandate the use of= UTC here?

 

Cheers,

 

Brian

 

On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) &= lt;timothy.carey@alcate= l-lucent.com> wrote:



Team,

 

 

I presented the calendar object to the BBF and suggested a timezone offset= parameter as defined in LMAP Information model.

 

object {

[datetime ma-calendar-start;] // default: immediate

[datetime ma-calendar-end;] // default: indefinite

[int ma-calendar-months<0..*>;] // default: 1-12

[days ma-calendar-weekdays<0..*>;] // default: all

[int ma-calendar-hours<0..*>;] // default: 0-23<= o:p>

[int ma-calendar-minutes<0..*>;] // default: 0-59

[int ma-calendar-seconds<0..*>;] // default: 0-59

[int ma-calendar-timezone-offset;]

// default: system timezone offset

} ma-calendar-obj;

 

 

What the BBHome group noted was th= at the datetime object type already has a timezone element associated with = the type.

 

So the suggestion is that that the= schedule should utilize the timezone of the start and end time parameters = and that we constrain these parameters to use the same timezone. This should solve the problem without the need for a timezone offset param= eter.

 

Thoughts?=

 

Thanks,

Tim=

______________________________________= _________
lmap mailing list
lmap@ietf.org=
https://www.ietf.org/mailman/listinfo/lmap

 

--_000_9966516C6EB5FC4381E05BF80AA55F7734EF4B11US70TWXCHMBA08z_-- From nobody Mon Jun 23 23:33: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 F374A1B2800 for ; Mon, 23 Jun 2014 23:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Jq7PSXQGP-mC for ; Mon, 23 Jun 2014 23:33:28 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5914D1B2839 for ; Mon, 23 Jun 2014 23:33:28 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id 59A571A0313; Tue, 24 Jun 2014 08:33:26 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_217DEE58-586C-4584-9B4D-C432D5917905"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> Date: Tue, 24 Jun 2014 08:33:25 +0200 Message-Id: <38E8A1EA-FDA3-45E9-9017-DEDD236C0757@trammell.ch> References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> To: "Carey, Timothy (Timothy)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/2d4ATRH7HxCtAbuTM6L-cjO7Ces Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 24 Jun 2014 06:33:33 -0000 --Apple-Mail=_217DEE58-586C-4584-9B4D-C432D5917905 Content-Type: multipart/alternative; boundary="Apple-Mail=_F7B84822-68C3-4DEC-87D6-922D706DE426" --Apple-Mail=_F7B84822-68C3-4DEC-87D6-922D706DE426 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Jun 2014, at 00:18, Carey, Timothy (Timothy) = wrote: > Brian, > =20 > There was a request for a time to be used as the local timezone of = host =96 when a timezone is not supplied. In my experience, this works really well in single-timezone operations = (e.g. most small-country national operators), less well but still = managably in multiple-timezone operations (e.g. US national-level), and = is a source of a whole lot of headache in global operations. But I = suppose most operations with this problem have already learned to stop = making these mistakes. > Calendar Timing is also required to perform measurements at > meaningful instances in relation to network usage (e.g., at peak > times). If the optional timezone offset is not supplied then local > system time is assumed. This is essential in some use cases to > ensure consistent peak-time measurements as well as supporting MA > devices that may be in an unknown timezone or roam between different > timezones (but know their own timezone information such as through > the mobile network). > =20 > So an ISO 8601 dateTime already has a timezone =96 so we should use = these if provided and we should constrain the start and end to use the = same time zone. ISO8601, IIRC, states timezones in absolute offset to UTC. So this would = introduce the corner case that a calendar that starts on one side of a = DST transition must continue using the pre-transition timezone, even = when the system time changes out from underneath the LMAP = application(s). > Unfortunately I think the ISO 8601 datetime states that an = undocumented timezone is undetermined. This is what the BBF uses for a = data type. > =20 > We could just state that an undocumented timezone is default timezone = of the system =96 that should work as well. Basing all this on 8601 does give operators the _choice_ to use local = timezone if they wish... but I do think we should warn = implementors/operator users about (1) the corner cases (DST) and (2) = issues with management/assumptions when controller/MA connections (or = MA/collector connections, but that's a reporting protocol issue) cross = TZ boundaries. That's a guideline in a different document. Alternately, we could state = in the information model that TZ MUST be explicit. Cheers, Brian > BR, > Tim > =20 > From: Brian Trammell [mailto:ietf@trammell.ch]=20 > Sent: Monday, June 23, 2014 3:41 PM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP Information model: Calendar schedules and = timezones > =20 > hi, Tim, all, > =20 > Is there any reason not to simply mandate the use of UTC here? > =20 > Cheers, > =20 > Brian > =20 > On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) = wrote: >=20 >=20 > Team, > =20 > =20 > I presented the calendar object to the BBF and suggested a timezone = offset parameter as defined in LMAP Information model. > =20 > object { > [datetime ma-calendar-start;] // default: immediate > [datetime ma-calendar-end;] // default: indefinite > [int ma-calendar-months<0..*>;] // default: 1-12 > [days ma-calendar-weekdays<0..*>;] // default: all > [int ma-calendar-hours<0..*>;] // default: 0-23 > [int ma-calendar-minutes<0..*>;] // default: 0-59 > [int ma-calendar-seconds<0..*>;] // default: 0-59 > [int ma-calendar-timezone-offset;] > // default: system timezone offset > } ma-calendar-obj; > =20 > =20 > What the BBHome group noted was that the datetime object type already = has a timezone element associated with the type. > =20 > So the suggestion is that that the schedule should utilize the = timezone of the start and end time parameters and that we constrain = these parameters to use the same timezone. This should solve the problem = without the need for a timezone offset parameter. > =20 > Thoughts? > =20 > Thanks, > Tim > _______________________________________________ > 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=_F7B84822-68C3-4DEC-87D6-922D706DE426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 24 Jun 2014, at 00:18, Carey, = Timothy (Timothy) <timothy.carey@alcatel-luc= ent.com> wrote:

Brian,
 
There was a request for a time to be used as = the local timezone of host =96 when a timezone is not = supplied.

In my = experience, this works really well in single-timezone operations (e.g. = most small-country national operators), less well but still managably in = multiple-timezone operations (e.g. US national-level), and is a source = of a whole lot of headache in global operations. But I suppose most = operations with this problem have already learned to stop making these = mistakes.

Calendar = Timing is also required to perform measurements = at
meaningful instances in = relation to network usage (e.g., at peak
times). If the optional timezone offset is not supplied then = local
system time is assumed. = This is essential in some use cases to
ensure consistent peak-time measurements as well as supporting = MA
devices that may be in = an unknown timezone or roam between = different
timezones (but know = their own timezone information such as = through
the mobile = network).
 
So an ISO 8601 dateTime already has a timezone = =96 so we should use these if provided and we should constrain the start = and end to use the same time = zone.

ISO8601, = IIRC, states timezones in absolute offset to UTC. So this would = introduce the corner case that a calendar that starts on one side of a = DST transition must continue using the pre-transition timezone, even = when the system time changes out from underneath the LMAP = application(s).

Unfortunately I = think the ISO 8601 datetime states that an undocumented timezone is = undetermined. This is what the BBF uses for a data = type.
 
We could just state that an = undocumented timezone is default timezone of the system =96 that should = work as = well.

Basing = all this on 8601 does give operators the _choice_ to use local timezone = if they wish... but I do think we should warn implementors/operator = users about (1) the corner cases (DST) and (2) issues with = management/assumptions when controller/MA connections (or MA/collector = connections, but that's a reporting protocol issue) cross TZ = boundaries.

That's a guideline in a different = document. Alternately, we could state  in the information model = that TZ MUST be = explicit.

Cheers,

Brian<= /div>


BR,
Tim
 
From: Brian Trammell [mailto:ietf@trammell.ch] 
Sent: Monday, June 23, 2014 3:41 = PM
To: Carey, = Timothy (Timothy)
Cc: lmap@ietf.org
Subject: Re: [lmap] LMAP Information = model: Calendar schedules and = timezones
 
hi, Tim, = all,
 
Is = there any reason not to simply mandate the use of UTC = here?
 
Cheers,
 
Brian
 
On 23 = Jun 2014, at 23:38, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com> = wrote:


Team,
 
 
I presented the calendar object to the BBF and suggested a = timezone offset parameter as defined in LMAP Information = model.
 
object {
[datetime ma-calendar-start;] // default: = immediate
[datetime = ma-calendar-end;] // default: indefinite
[int = ma-calendar-months<0..*>;] // default: 1-12
[days = ma-calendar-weekdays<0..*>;] // default: all
[int = ma-calendar-hours<0..*>;] // default: 0-23
[int = ma-calendar-minutes<0..*>;] // default: 0-59
[int = ma-calendar-seconds<0..*>;] // default: 0-59
[int = ma-calendar-timezone-offset;]
// = default: system timezone offset
} = ma-calendar-obj;
 
 
What the BBHome group noted was that the datetime object = type already has a timezone element associated with the = type.
 
So the suggestion is that that the schedule = should utilize the timezone of the start and end time parameters and = that we constrain these parameters to use the same timezone. This should = solve the problem without the need for a timezone offset = parameter.
 
Thoughts?
 
Thanks,
Tim
_______________________________________________
lmap = mailing list
lmap@ietf.org
https://www.ietf.org/mailman/listinfo/lmap<= /span>
 
_______________________________= ________________
lmap mailing list
lmap@ietf.org
https://www.ietf.org/ma= ilman/listinfo/lmap

= --Apple-Mail=_F7B84822-68C3-4DEC-87D6-922D706DE426-- --Apple-Mail=_217DEE58-586C-4584-9B4D-C432D5917905 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 iQEcBAEBCgAGBQJTqRu1AAoJENt3nsOmbNJcwgsIAJ6PlbbucpmCI7rDYhySgwg0 XhKzrPmISCWjRggDLKsktoMYjNOaQneY59bTvNG6pKBzz3E+OqDSDrEQE/TSQ6Jt lMNdPoBF68yK340GoBq8xzuIEyYcLO7iBzEWMaagYD6IOTxlHRxH/6WNEgh9iOJh 3OW3e4EyDoJT7rw+zh44q+VKb5kOTEMgj0Hm7tSSyQwbSVtsw8+Irx1V3KFBQKo/ lFM6JR+Jnxht4K94yGPd2XuqEI9GDXOygHNsVdhQ+1XJQZvC8+MWfX0PVvhRefDr nPDsCl8nVhVt/ensAAtDarvS5aBgSAD1VMc+La8bR26jQYQxs//wpSbKxkxiDAI= =SDXJ -----END PGP SIGNATURE----- --Apple-Mail=_217DEE58-586C-4584-9B4D-C432D5917905-- From nobody Tue Jun 24 00:53: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 5E2F51B2845; Tue, 24 Jun 2014 00:53:26 -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 TzbOmDRJw78E; Tue, 24 Jun 2014 00:53:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF211B2877; Tue, 24 Jun 2014 00:53:23 -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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624075323.17306.10620.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 00:53:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/6-LvTNkL38yat-plWzEQ64dGH-g Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-framework-07.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: Tue, 24 Jun 2014 07:53:26 -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-07.txt Pages : 54 Date : 2014-06-24 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-framework-07 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 Tue Jun 24 07:02: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 247E41B2A13 for ; Tue, 24 Jun 2014 07:02:09 -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 i-cPsD2oiCn0 for ; Tue, 24 Jun 2014 07:02:06 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F001B29CF for ; Tue, 24 Jun 2014 07:02:04 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 15:02:09 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.232]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 24 Jun 2014 15:01:59 +0100 From: To: , Date: Tue, 24 Jun 2014 15:01:59 +0100 Thread-Topic: [lmap] LMAP Information model: Calendar schedules and timezones Thread-Index: Ac+PLlaQ12IYpFFWRaiT3lwWUn8yRgAhgTfw Message-ID: References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> In-Reply-To: <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> 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_ED51D9282D1D3942B9438CA8F3372EB72DA89CF8B6EMV64UKRDdoma_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/w0kdIuJ0NZffbF-jAY_4E8kMKJw Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 24 Jun 2014 14:02:09 -0000 --_000_ED51D9282D1D3942B9438CA8F3372EB72DA89CF8B6EMV64UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian UTC is mandatory in the information model wherever we have a time/date. How= ever, in expressing the list of hours in which the measurement is to run we= also need to express an offset to provide the same functionality. In this = way we can say, for example, to run the test during the hours 18, 19, 20, 2= 1 and 22 local time to measure 'peak' performance. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell Sent: 23 June 2014 22:41 To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezone= s hi, Tim, all, Is there any reason not to simply mandate the use of UTC here? Cheers, Brian On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) > wrote: Team, I presented the calendar object to the BBF and suggested a timezone offset = parameter as defined in LMAP Information model. object { [datetime ma-calendar-start;] // default: immediate [datetime ma-calendar-end;] // default: indefinite [int ma-calendar-months<0..*>;] // default: 1-12 [days ma-calendar-weekdays<0..*>;] // default: all [int ma-calendar-hours<0..*>;] // default: 0-23 [int ma-calendar-minutes<0..*>;] // default: 0-59 [int ma-calendar-seconds<0..*>;] // default: 0-59 [int ma-calendar-timezone-offset;] // default: system timezone offset } ma-calendar-obj; What the BBHome group noted was that the datetime object type already has a= timezone element associated with the type. So the suggestion is that that the schedule should utilize the timezone of = the start and end time parameters and that we constrain these parameters to= use the same timezone. This should solve the problem without the need for = a timezone offset parameter. Thoughts? Thanks, Tim _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap --_000_ED51D9282D1D3942B9438CA8F3372EB72DA89CF8B6EMV64UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian

 

UTC is mandatory in the= information model wherever we have a time/date. However, in expressing the= list of hours in which the measurement is to run we also need to express a= n offset to provide the same functionality. In this way we can say, for exa= mple, to run the test during the hours 18, 19, 20, 21 and 22 local time to = measure ‘peak’ performance.

 

Trev= or.

 

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm'>

From: lmap [mailto:lma= p-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: 23 J= une 2014 22:41
To: Carey, Timothy (Timothy)
Cc: lmap@ie= tf.org
Subject: Re: [lmap] LMAP Information model: Calendar sched= ules and timezones

 

hi, Tim, all,

 

Is = there any reason not to simply mandate the use of UTC here?

<= /div>

 

Cheers,

 <= /o:p>

Brian

 

On 23= Jun 2014, at 23:38, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com> wrote:<= o:p>



<= p class=3DMsoNormal>Team,

&= nbsp;

 

I presented the calenda= r object to the BBF and suggested a timezone offset parameter as defined in= LMAP Information model.

 

obje= ct {

[datetime ma-= calendar-start;] // default: immediate

[datetime ma-calendar-end;] // default: indefinite

[int ma-calendar-mo= nths<0..*>;] // default: 1-12

[days ma-calendar-weekdays<0..*>;] // default: all<= /span>

[int ma-calendar-h= ours<0..*>;] // default: 0-23

[int ma-calendar-minutes<0..*>;] // default: 0-59

[int ma-calendar-se= conds<0..*>;] // default: 0-59

[int ma-calendar-timezone-offset;]

// default: system timezone offset

} ma-calendar-obj;

 =

 

What the BBHome group noted was that the datetime object type already has = a timezone element associated with the type.=

 

So the suggestion i= s that that the schedule should utilize the timezone of the start and end t= ime parameters and that we constrain these parameters to use the same timez= one. This should solve the problem without the need for a timezone offset p= arameter.

 

Thoughts?

 

<= /div>

Thanks,

Tim

__________________________= _____________________
lmap mailing list
lmap@ietf.org
https= ://www.ietf.org/mailman/listinfo/lmap

 

<= /html>= --_000_ED51D9282D1D3942B9438CA8F3372EB72DA89CF8B6EMV64UKRDdoma_-- From nobody Tue Jun 24 07:05: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 E42251B2948 for ; Tue, 24 Jun 2014 07:05:05 -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 xOcg0nLoxHXD for ; Tue, 24 Jun 2014 07:05:01 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9088F1B2A28 for ; Tue, 24 Jun 2014 07:04:58 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 91B0A1A13F5; Tue, 24 Jun 2014 16:04:57 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0066276F-9C70-4D1A-8261-EFAEEB886187"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Tue, 24 Jun 2014 16:05:00 +0200 Message-Id: References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> To: trevor.burbridge@bt.com X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oQs4UsOPKq_Kcp3o28e9Es91i94 Cc: timothy.carey@alcatel-lucent.com, lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 24 Jun 2014 14:05:06 -0000 --Apple-Mail=_0066276F-9C70-4D1A-8261-EFAEEB886187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Trevor, Okay, got it. There should still be documentation of corner cases = (though in your "peak hour" use case, you generally won't be running the = test through a DST transition :) ), and a note for implementors (though = probably not in the information model) that this is something that's = quite easy to get wrong in a confusing way. Cheers, Brian On 24 Jun 2014, at 16:01, = wrote: > Hi Brian > =20 > UTC is mandatory in the information model wherever we have a = time/date. However, in expressing the list of hours in which the = measurement is to run we also need to express an offset to provide the = same functionality. In this way we can say, for example, to run the test = during the hours 18, 19, 20, 21 and 22 local time to measure =91peak=92 = performance. > =20 > Trevor. > =20 > =20 > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: 23 June 2014 22:41 > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] LMAP Information model: Calendar schedules and = timezones > =20 > hi, Tim, all, > =20 > Is there any reason not to simply mandate the use of UTC here? > =20 > Cheers, > =20 > Brian > =20 > On 23 Jun 2014, at 23:38, Carey, Timothy (Timothy) = wrote: >=20 >=20 > Team, > =20 > =20 > I presented the calendar object to the BBF and suggested a timezone = offset parameter as defined in LMAP Information model. > =20 > object { > [datetime ma-calendar-start;] // default: immediate > [datetime ma-calendar-end;] // default: indefinite > [int ma-calendar-months<0..*>;] // default: 1-12 > [days ma-calendar-weekdays<0..*>;] // default: all > [int ma-calendar-hours<0..*>;] // default: 0-23 > [int ma-calendar-minutes<0..*>;] // default: 0-59 > [int ma-calendar-seconds<0..*>;] // default: 0-59 > [int ma-calendar-timezone-offset;] > // default: system timezone offset > } ma-calendar-obj; > =20 > =20 > What the BBHome group noted was that the datetime object type already = has a timezone element associated with the type. > =20 > So the suggestion is that that the schedule should utilize the = timezone of the start and end time parameters and that we constrain = these parameters to use the same timezone. This should solve the problem = without the need for a timezone offset parameter. > =20 > Thoughts? > =20 > Thanks, > Tim > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --Apple-Mail=_0066276F-9C70-4D1A-8261-EFAEEB886187 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 iQEcBAEBCgAGBQJTqYWNAAoJENt3nsOmbNJca8EH/jSitXcOYzVimZcAl9BM9BM2 cSIzsSAtaou7R/TMswtHRbZ9xD6mCmYEVngWqrm+RibeXCngE6FLXdEEtoMGTXD8 gH6IxpfTO5T4RVO6s6TXjbyRD0+PHjpp9Ryrx7hgCOXCyf0zSMwIefCBb4Svaim1 55KY2S678X9ofvJHN8+nEmwGVB8HKhpzu8XNM9pdk5s6O8nu+/JI5jV/LLu/Ao3S CdaioFAkI8JQRGu/AQLaHR/H5NogHDRcpxHWz22YnhmpJZYSM8urtyRtAC/qcc6f fPzsCdb7KkXDPynUYNmrCCDNPmul9rZNA50D7PbpZNMBsmkJ1EugaLv87WYjDsU= =yRzD -----END PGP SIGNATURE----- --Apple-Mail=_0066276F-9C70-4D1A-8261-EFAEEB886187-- From nobody Tue Jun 24 09:09:48 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 614E91B2D7C for ; Tue, 24 Jun 2014 09:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 KgVi_3dtcUQn for ; Tue, 24 Jun 2014 09:09:45 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9A1B2E3E for ; Tue, 24 Jun 2014 09:04:32 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,539,1400040000"; d="scan'208,217";a="371132311" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jun 2014 12:04:13 -0400 Received: from PRVPEXVS06.corp.twcable.com ([10.136.163.33]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 24 Jun 2014 12:04:31 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Tue, 24 Jun 2014 12:04:30 -0400 Thread-Topic: draft-ietf-lmap-framework-07 3rd WGLC Thread-Index: Ac+PxftfXMxX3AHNTey1L9XuqhjVaQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFCF19CE2F823jasonweiltwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_fhle-z2idLCFeVfYEZJW0hbGn0 Subject: [lmap] draft-ietf-lmap-framework-07 3rd WGLC 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, 24 Jun 2014 16:09:47 -0000 --_000_CFCF19CE2F823jasonweiltwcablecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to initiate a two week working group last call on http://tools.ietf= .org/html/draft-ietf-lmap-framework-07 There has been extensive discussion= on a number of items following the 2nd WGLC and the chairs would like fee= dback from the WG to see if all major concerns have been addressed. Please = take a look at this updated version and provide comments or a statement of= support for draft as written to the list by July 8th. Nits and minor edits= can be sent to the authors. Thanks, Jason ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_CFCF19CE2F823jasonweiltwcablecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is to initiate a two week working group last call on http://tools.i= etf.org/html/draft-ietf-lmap-framework-07  There has been extensiv= e discussion on a number of items  following the 2nd WGLC and the chairs would like feedback from the WG to see if all = major concerns have been addressed. Please take a look at this updated vers= ion and provide  comments or a statement of support for draft as writt= en to the list by July 8th. Nits and minor edits can be sent to the authors. 

Thanks,

Jason



This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_CFCF19CE2F823jasonweiltwcablecom_-- From nobody Thu Jun 26 03:44:41 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 18CCA1B2B24 for ; Thu, 26 Jun 2014 03:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 v0tdN-J_MT2A for ; Thu, 26 Jun 2014 03:44:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D203B1B2A61 for ; Thu, 26 Jun 2014 03:44:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6D201736; Thu, 26 Jun 2014 12:44:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Th-bNulhNQnd; Thu, 26 Jun 2014 12:44:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jun 2014 12:44:34 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC08B20043; Thu, 26 Jun 2014 12:44:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mbQ8qs3m5Xn4; Thu, 26 Jun 2014 12:44:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F5A320040; Thu, 26 Jun 2014 12:44:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 088212D9A08A; Thu, 26 Jun 2014 12:44:34 +0200 (CEST) Date: Thu, 26 Jun 2014 12:44:33 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140626104433.GB24344@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , Brian Trammell , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-_peq_U-BxhrgN8o2SCa3V9pG2E Cc: Brian Trammell , "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 26 Jun 2014 10:44:39 -0000 On Mon, Jun 23, 2014 at 10:18:17PM +0000, Carey, Timothy (Timothy) wrote: > So an ISO 8601 dateTime already has a timezone - so we should use these if provided and we should constrain the start and end to use the same time zone. > > Unfortunately I think the ISO 8601 datetime states that an undocumented timezone is undetermined. This is what the BBF uses for a data type. > > We could just state that an undocumented timezone is default timezone of the system - that should work as well. > Just for clarity, I think what we want to use is RFC 3339, which defines the "Internet Date/Time Format", which is essentially ISO 8601 but with a few important simplifications. /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 Jun 26 05:36: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 CD2531B2BA1 for ; Thu, 26 Jun 2014 05:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, 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 QTV4nfc1xych for ; Thu, 26 Jun 2014 05:36:18 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0514E1B2BA6 for ; Thu, 26 Jun 2014 05:36:17 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5QCaFht025103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 07:36:15 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5QCaERb019823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 08:36:15 -0400 Received: from US70TWXCHMBA08.zam.alcatel-lucent.com ([169.254.2.45]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 26 Jun 2014 08:36:14 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Information model: Calendar schedules and timezones Thread-Index: Ac+PKt77zr1NBQUETbWuHypUl1ndKwAInWGAAAhPBDAAd6UEgAAE28CQ Date: Thu, 26 Jun 2014 12:36:13 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734EFB1AC@US70TWXCHMBA08.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> <20140626104433.GB24344@elstar.local> In-Reply-To: <20140626104433.GB24344@elstar.local> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/Jac6EZa8gdKl8frzm2V4IsE8_vw Cc: Brian Trammell , "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 26 Jun 2014 12:36:21 -0000 Juergen, We can do that but we will have to define a new data type for date time tha= n the one used by BBF which is the standard xs:datetime from SOAP (ISO 8601= ). I saw in the information model that it indeed does reference RFC3339. So then would we say a datetime without a timestamp is UTC and datetime wit= h -00:00 is system local and we use the starttime for the timezone of the s= chedule (which isn't datetime)? A TR-069 device already has has a system local timezone - so for BBF we wil= l not need an additional parameter as part of the schedule - since it is al= ready part of the device. What do you think? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, June 26, 2014 4:45 AM To: Carey, Timothy (Timothy) Cc: Brian Trammell; lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezone= s On Mon, Jun 23, 2014 at 10:18:17PM +0000, Carey, Timothy (Timothy) wrote: > So an ISO 8601 dateTime already has a timezone - so we should use these i= f provided and we should constrain the start and end to use the same time z= one. >=20 > Unfortunately I think the ISO 8601 datetime states that an undocumented t= imezone is undetermined. This is what the BBF uses for a data type. >=20 > We could just state that an undocumented timezone is default timezone of = the system - that should work as well. >=20 Just for clarity, I think what we want to use is RFC 3339, which defines th= e "Internet Date/Time Format", which is essentially ISO 8601 but with a few= important simplifications. /js --=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 Thu Jun 26 05:55: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 92E831B2BB3 for ; Thu, 26 Jun 2014 05:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 xv9-LBvr9rMA for ; Thu, 26 Jun 2014 05:55:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6938C1B2BB0 for ; Thu, 26 Jun 2014 05:55:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0578613AC; Thu, 26 Jun 2014 14:55:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uZAfaTd4UGko; Thu, 26 Jun 2014 14:55:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jun 2014 14:55:32 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B1DF20040; Thu, 26 Jun 2014 14:55:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5yx68_Fj9i1i; Thu, 26 Jun 2014 14:55:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5665120043; Thu, 26 Jun 2014 14:55:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A28C2D9A326; Thu, 26 Jun 2014 14:55:31 +0200 (CEST) Date: Thu, 26 Jun 2014 14:55:30 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20140626125530.GD24646@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , Brian Trammell , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> <20140626104433.GB24344@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734EFB1AC@US70TWXCHMBA08.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F7734EFB1AC@US70TWXCHMBA08.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jiQ4IRyLJo58hi35zdtCyf56lWw Cc: Brian Trammell , "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 26 Jun 2014 12:55:36 -0000 On Thu, Jun 26, 2014 at 12:36:13PM +0000, Carey, Timothy (Timothy) wrote: > > So then would we say a datetime without a timestamp is UTC and > datetime with -00:00 is system local and we use the starttime for > the timezone of the schedule (which isn't datetime)? Not sure what you mean with "timestamp". Let me assume you mean 'time-offset'. Then yes, my understanding is that you would use -00:00 if the timezone offset is unknown and things are interpreted to the notion of time local on the system. BTW, the definition of data-and-time in RFC 6021 summarizes how I understand the difference between XSDs dateTime type and RFC 3339. (And I think XSDs dateTime is again a profile of the ISO 8601 definition.) /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 Jun 26 06:03:13 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 464C71B2DE0 for ; Thu, 26 Jun 2014 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vr59V6qPSSKe for ; Thu, 26 Jun 2014 06:03:08 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543461B2BF7 for ; Thu, 26 Jun 2014 06:02:28 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5QD2ROc006614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2014 08:02:27 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s5QD2RNA031448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 09:02:27 -0400 Received: from US70TWXCHMBA08.zam.alcatel-lucent.com ([169.254.2.45]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 26 Jun 2014 09:02:27 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] LMAP Information model: Calendar schedules and timezones Thread-Index: Ac+PKt77zr1NBQUETbWuHypUl1ndKwAInWGAAAhPBDAAd6UEgAAE28CQ///9uACAAEE64A== Date: Thu, 26 Jun 2014 13:02:26 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F7734EFCA9E@US70TWXCHMBA08.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F7734EF4933@US70TWXCHMBA08.zam.alcatel-lucent.com> <8B09A7EB-A564-473A-9B76-BE02E56BCD0C@trammell.ch> <9966516C6EB5FC4381E05BF80AA55F7734EF4B11@US70TWXCHMBA08.zam.alcatel-lucent.com> <20140626104433.GB24344@elstar.local> <9966516C6EB5FC4381E05BF80AA55F7734EFB1AC@US70TWXCHMBA08.zam.alcatel-lucent.com> <20140626125530.GD24646@elstar.local> In-Reply-To: <20140626125530.GD24646@elstar.local> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/oxWRDWriwHmpMOH_xsBekUNu5gI Cc: Brian Trammell , "lmap@ietf.org" Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezones 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, 26 Jun 2014 13:03:12 -0000 Yes that is what I meant; I will take a look at RFC 6021; thanks. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, June 26, 2014 6:56 AM To: Carey, Timothy (Timothy) Cc: Brian Trammell; lmap@ietf.org Subject: Re: [lmap] LMAP Information model: Calendar schedules and timezone= s On Thu, Jun 26, 2014 at 12:36:13PM +0000, Carey, Timothy (Timothy) wrote: >=20 > So then would we say a datetime without a timestamp is UTC and=20 > datetime with -00:00 is system local and we use the starttime for the=20 > timezone of the schedule (which isn't datetime)? Not sure what you mean with "timestamp". Let me assume you mean 'time-offse= t'. Then yes, my understanding is that you would use -00:00 if the timezone= offset is unknown and things are interpreted to the notion of time local o= n the system. BTW, the definition of data-and-time in RFC 6021 summarizes how I understan= d the difference between XSDs dateTime type and RFC 3339. (And I think XSDs dateTime is again a profile of the ISO 8601 definition.) /js --=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 Fri Jun 27 07:48: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 ED7D91B31E5; Fri, 27 Jun 2014 07:48:23 -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 zdQqdIx4HJHB; Fri, 27 Jun 2014 07:48:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE61B31EB; Fri, 27 Jun 2014 07:48:21 -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.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140627144821.2131.33488.idtracker@ietfa.amsl.com> Date: Fri, 27 Jun 2014 07:48:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/QW4c_pb3CL4lU4SzVLTUpPERPO0 Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:48:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-01.txt Pages : 35 Date : 2014-06-26 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 27 08:52:53 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 D6A4D1B2E96 for ; Fri, 27 Jun 2014 08:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 jRsx2K6Vrtr5 for ; Fri, 27 Jun 2014 08:52:49 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270031B2C00 for ; Fri, 27 Jun 2014 08:52:49 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 0539da35.0.1936923.00-2258.3700428.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 27 Jun 2014 15:52:49 +0000 (UTC) X-MXL-Hash: 53ad935121834798-e1c1c70b7cbfda3fbdcd562b0c6a704e4efdf48e 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 s5RFqlZs029559 for ; Fri, 27 Jun 2014 11:52:48 -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 s5RFqfRD029479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jun 2014 11:52:43 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi132.aldc.att.com (RSA Interceptor) for ; Fri, 27 Jun 2014 15:52:30 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.91]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.03.0174.001; Fri, 27 Jun 2014 11:52:30 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt Thread-Index: AQHPkhbd28JkueigjEy5v017TaUOGZuFD5ow Date: Fri, 27 Jun 2014 15:52:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DFBF22@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20140627144821.2131.33488.idtracker@ietfa.amsl.com> In-Reply-To: <20140627144821.2131.33488.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.86.72] 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=C9NeP3z+ c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Cmc5sUHs0TQA:10 a=ofMgfj31e3cA:10 a=eEw-T-YevoUA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=yvZGru5oBmSbasWjyY0A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=eS2ylfgho05etL_Y:21 a=ZlG88-s] X-AnalysisOut: [m5Ds6uj-h:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/_o-ou1MI1-B9Q7LvxhUqlvdFVqY Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:52:52 -0000 It seems the discussion of "Active Measurement" and "Passive Measurement" c= ould be removed from information-model since nothing in the actual model ca= res about this distinction and we took it out of framework? It's clear from the text that not all ma-task-obj instances are Measurement= Tasks. That's fine. But this does create some ambiguity for me around Supp= ression. Framework-07 clearly defines Suppression as a temporary cessation = of Measurement Tasks. It makes no mention of other sorts of "tasks" that ma= y or may not be indistinguishable from Measurement Tasks in the information= -model. So I think that information-model needs to have an explicit statement regar= ding behavior around suppression of non Measurement Task ma-task-obj instan= ces that happen to be included as a ma-suppression-task-name in a ma-suppre= ssion-obj . I see 2 possibilities. Either such ma-task-obj instances - will not be suppressed or=20 - whether or not they will be suppressed is left up to the implementation = and suppression / non-suppression cannot be assumed Barbara > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, June 27, 2014 10:48 AM > To: i-d-announce@ietf.org > Cc: lmap@ietf.org > Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Large-Scale Measurement of Broadband > Performance Working Group of the IETF. >=20 > Title : Information Model for Large-Scale Measurement P= latforms > (LMAP) > Authors : Trevor Burbridge > Philip Eardley > Marcelo Bagnulo > Juergen Schoenwaelder > Filename : draft-ietf-lmap-information-model-01.txt > Pages : 35 > Date : 2014-06-26 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lmap-information-model-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-information-model-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Jun 30 01:59:41 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 F1ED71A01B0 for ; Mon, 30 Jun 2014 01:59:39 -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 Vz7YreZctDJZ for ; Mon, 30 Jun 2014 01:59:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E794C1A01A7 for ; Mon, 30 Jun 2014 01:59:36 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 30 Jun 2014 09:59:39 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.2.87]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 30 Jun 2014 09:59:34 +0100 From: To: , Date: Mon, 30 Jun 2014 09:59:34 +0100 Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt Thread-Index: AQHPkhbd28JkueigjEy5v017TaUOGZuFD5owgAROQvA= Message-ID: References: <20140627144821.2131.33488.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130DFBF22@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130DFBF22@GAALPA1MSGUSRBF.ITServices.sbc.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/fOP4qXQBKDYljK6QK_v9cI2XZXk Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-01.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, 30 Jun 2014 08:59:40 -0000 There is an explcit statement at the moment about what will happen: - every task can use the "suppress-by-default flag" - the suppression will affect ALL tasks in the Instruction - by default if = the above flag is TRUE (default is TRUE) or explicitly if listed. i.e. the information model is completely agnostic to the concepts of active= vs. passive and measurement vs. non-measurement. We can, of course, discuss if this is what you want to happen! I took this = as the concensus opinion of the various discussions over the last month. Trevor. >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H >Sent: 27 June 2014 16:52 >To: lmap@ietf.org >Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt > >It seems the discussion of "Active Measurement" and "Passive Measurement" >could be removed from information-model since nothing in the actual model >cares about this distinction and we took it out of framework? > >It's clear from the text that not all ma-task-obj instances are Measuremen= t Tasks. >That's fine. But this does create some ambiguity for me around Suppression= . >Framework-07 clearly defines Suppression as a temporary cessation of >Measurement Tasks. It makes no mention of other sorts of "tasks" that may = or >may not be indistinguishable from Measurement Tasks in the information-mod= el. > >So I think that information-model needs to have an explicit statement rega= rding >behavior around suppression of non Measurement Task ma-task-obj instances >that happen to be included as a ma-suppression-task-name in a ma-suppressi= on- >obj . > >I see 2 possibilities. Either such ma-task-obj instances > - will not be suppressed or > - whether or not they will be suppressed is left up to the implementation= and >suppression / non-suppression cannot be assumed Barbara > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, June 27, 2014 10:48 AM >> To: i-d-announce@ietf.org >> Cc: lmap@ietf.org >> Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt >> >> >> 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-01.txt >> Pages : 35 >> Date : 2014-06-26 >> >> 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-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-information-model-01 >> >> >> 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 > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Jun 30 05:45:35 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 464871A0302 for ; Mon, 30 Jun 2014 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 E4pe8f5zYLye for ; Mon, 30 Jun 2014 05:45:31 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A641A02BB for ; Mon, 30 Jun 2014 05:45:31 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c11o144.mxlogic.net(mxl_mta-8.0.0-2) with ESMTP id beb51b35.2b96df61e940.17414.00-537.45288.p01c11o144.mxlogic.net (envelope-from ); Mon, 30 Jun 2014 06:45:31 -0600 (MDT) X-MXL-Hash: 53b15beb7830f9e6-0038bcb510a48d7d1d9171c00c3c50a3520840f2 Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by p01c11o144.mxlogic.net(mxl_mta-8.0.0-2) over TLS secured channel with ESMTP id 58a51b35.0.14721.00-354.38052.p01c11o144.mxlogic.net (envelope-from ); Mon, 30 Jun 2014 06:39:36 -0600 (MDT) X-MXL-Hash: 53b15a8866d27bb6-c111f182040f0cf714b3368a46dbf0282e0d7d0c Received: from ex-mb2.corp.adtran.com ([fe80::7066:bf43:c7f9:c72b]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0181.006; Mon, 30 Jun 2014 07:39:32 -0500 From: KEN KO To: "trevor.burbridge@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt Thread-Index: AQHPkhbbuAWF1UbWjEGOC3/ljN7FrJuFbz2AgARDoAD//+hSkA== Date: Mon, 30 Jun 2014 12:39:31 +0000 Message-ID: References: <20140627144821.2131.33488.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E61130DFBF22@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.5.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=OJ+p3EqB c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=Cmc5sUHs0TQA:10 a=qZH] X-AnalysisOut: [QZMT3apYA:10 a=bLVtjD-Y068A:10 a=BLceEmwcHowA:10 a=kj9zAlc] X-AnalysisOut: [Oel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpioGAAAA:8 a=YlVTAMxIAAAA] X-AnalysisOut: [:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=zQP7CpKOAAAA:8 a=Pm] X-AnalysisOut: [UfFuYGIJMvgiEVbdMA:9 a=XmHnxCs3klfFeKNG:21 a=VR1AujKqeT4w_] X-AnalysisOut: [u-q:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:] X-AnalysisOut: [10 a=Hz7IrDYlS0cA:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014063011); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/i7hiq8lDvY6xEOBGRWIXVXnRsdA Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-01.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, 30 Jun 2014 12:45:34 -0000 I agree with Trevor - let's use the mechanism we've just defined for all Ta= sks, Measurement and Otherwise. - Ken -----Original Message----- From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of trevor.burbridge@bt.= com Sent: Monday, June 30, 2014 5:00 AM To: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt There is an explcit statement at the moment about what will happen: - every task can use the "suppress-by-default flag" - the suppression will affect ALL tasks in the Instruction - by default if = the above flag is TRUE (default is TRUE) or explicitly if listed. i.e. the information model is completely agnostic to the concepts of active= vs. passive and measurement vs. non-measurement. We can, of course, discuss if this is what you want to happen! I took this = as the concensus opinion of the various discussions over the last month. Trevor. >-----Original Message----- >From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of STARK, BARBARA H >Sent: 27 June 2014 16:52 >To: lmap@ietf.org >Subject: Re: [lmap] I-D Action:=20 >draft-ietf-lmap-information-model-01.txt > >It seems the discussion of "Active Measurement" and "Passive Measurement" >could be removed from information-model since nothing in the actual=20 >model cares about this distinction and we took it out of framework? > >It's clear from the text that not all ma-task-obj instances are Measuremen= t Tasks. >That's fine. But this does create some ambiguity for me around Suppression= . >Framework-07 clearly defines Suppression as a temporary cessation of=20 >Measurement Tasks. It makes no mention of other sorts of "tasks" that=20 >may or may not be indistinguishable from Measurement Tasks in the informat= ion-model. > >So I think that information-model needs to have an explicit statement=20 >regarding behavior around suppression of non Measurement Task=20 >ma-task-obj instances that happen to be included as a=20 >ma-suppression-task-name in a ma-suppression- obj . > >I see 2 possibilities. Either such ma-task-obj instances > - will not be suppressed or > - whether or not they will be suppressed is left up to the=20 >implementation and suppression / non-suppression cannot be assumed=20 >Barbara > >> -----Original Message----- >> From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of internet-=20 >> drafts@ietf.org >> Sent: Friday, June 27, 2014 10:48 AM >> To: i-d-announce@ietf.org >> Cc: lmap@ietf.org >> Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-01.txt >> >> >> 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=20 >> 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-01.txt >> Pages : 35 >> Date : 2014-06-26 >> >> 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-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lmap-information-model-01 >> >> >> Please note that it may take a couple of minutes from the time of=20 >> 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 > >_______________________________________________ >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

Barbara,<= /o:p>

 

Thanks for the comments – and for the nits (which I= 217;ll look at later)

&nbs= p;

On the first, sorry to have misse= d this, happy to delete the offending sentence.

 

On the = second, I actually think most of these considerations are applicable whethe= r the mA “pushes” the results or whether the Collector “p= ulls” them.

Certainly <= ;< limit the memory/storage consumed by a single MA's reports>>= also I think the transmission rate. I guess limiting the number of connect= ions from a MA is more applicable to push (at least is simple in the pull c= ase!)

 

Maybe the best thing is simply to delete the final paragraph – d= on’t think it adds anything that hasn’t been said elsewhere. So= delete

<< Many of the above conside= rations are applicable to a "pull" model,

   where the MA must contact the Controller because NAT= or other network

   aspect pr= events Controllers from contacting MAs directly.

>> 

=  

phil=

 

From: STARK, BARBARA H [mailt= o:bs7652@att.com]
Sent: 18 June 2014 19:07
To: Eardley= ,PL,Philip,TUB8 R; lmap@ietf.org
Subject: RE: new version of fram= ework

 

I hav= e just 2 comments. I’m also emailing a marked up Word version to the = authors, that notes all nits that I found.

------

5.6.1.  End-user-controlled measurement system<= /o:p>

...

 &nbs= p; 1.  an end-user could somehow request the ISP- (or regulator-) run<= o:p>

       measu= rement system to test his/her line.  The ISP (or regulator)=

       Controller woul= d then send an Instruction to the MA in the usual

       LMAP way.  Note that a us= er can't directly initiate a Measurement

&= nbsp;      Task on an ISP- (or regulator-) control= led MA.

 

In a comment to t= he -04 version I’d asked to have the last sentence deleted. I didn= 217;t really follow up on this among all the other comments. But I still fi= nd this to be an unnecessary restriction. We have lots of devices that coul= d be considered to have MAs that have both a “controller” inter= face that allows for all Controller - MA activities, and a local user inter= face for a limited set of user-requested actions. I don’t think this = should become prohibited and that we should be forced to remove such a loca= l user interface just to make the MA “compliant” to this framew= ork. This is an unnecessary sentence.

------

7.  Security considerations

...

   Since Collectors will= be contacted repeatedly by MAs using the

=    Collection Protocol to convey their recent results, a successf= ul

   attack to exhaust the comm= unication resources would prevent a

 =   critical operation: reporting.  Therefore, all LMAP Collectors = should

   implement technical me= chanisms to:

 

<= p class=3DMsoPlainText>   o  limit the number of reporting connections f= rom a single MA

    &n= bsp; (simultaneous, and connections per unit time).

 

   o  limi= t the transmission rate from a single MA.

=  

   o  limit the memo= ry/storage consumed by a single MA's reports.

 

   o  efficientl= y reject reporting connections from unknown sources.

<= p class=3DMsoPlainText> 

   o  s= eparate resources if multiple authentication strengths are used,=

      where the resources s= hould be separated according to each class of

      strength.

 

   o  limit iter= ation counters to generate keys with both a lower and

=

      upper limit, to prevent an attac= king system from requesting the

 &nbs= p;    maximum and causing the Controller to stall on the pro= cess (see

      s= ection 6 of [RFC5357]).

 <= /span>

   Many of the above considerations are app= licable to a "pull" model,

 = ;  where the MA must contact the Controller because NAT or other netwo= rk

   aspect prevents Controller= s from contacting MAs directly.

 = ;

The list above this last paragraph is all related to the MA to Colle= ctor interface. In the context of that interface, per descriptions in 5.5, = these considerations are applicable to the “push” model (where = the MA contacts the Collector) and not the “pull” model.

 

Barbara

 

 

From:= lmap [mailto:lmap-bounces@ie= tf.org] On Behalf Of ph= ilip.eardley@bt.com
Sent: Friday, June 13, 2014 8:39 AM
To: lmap@ietf.org
Subject:<= /b> [lmap] new version of framework

 

I= just uploaded a new version

http://www.ietf.org/= id/draft-ietf-lmap-framework-06.txt

 

Barbara, Greg, Ken and others whoR= 17;ve made suggestions - Please could you do a quick check to make sure we = got your points properly

 =

Thanks

Phil

 

--12.6.  From=
 -05 to -06

 

   o  clarified terminlogy around Measurement Methods= and Tasks.  Since

   = ;   within a Method there may be several different roles (request= er

      and res= ponder, for instance)

 

   o  Suppression: there is now the co= ncept of a flag (boolean) which

<= span style=3D'font-size:10.0pt;font-family:"Courier New","serif"'> &nb= sp;    indicates whether a Task is by default gets suppresse= d or not.

      = The optional suppression message (with list of specific tasks

      /schedules to suppress)= over-rides this flag.

 <= /span>

   o  The previous bullet also means = there is no need to make a

  &n= bsp;   distinction between active and passive Measurement Tasks, = so this

      di= stinction is removed.

 

I now see a glitch! The final 2 bullets should be rep= laced by:-

 

   o  removed Configuration Protocol – Conf= iguration is part of the Instruction and so uses the Control Protocol<= /o:p>