From nobody Fri Aug 12 02:03:15 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3DD12D0DE for ; Fri, 12 Aug 2016 02:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 mLwzFKaI128m for ; Fri, 12 Aug 2016 02:03:09 -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 08E0312D104 for ; Fri, 12 Aug 2016 02:03:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7C24B1000 for ; Fri, 12 Aug 2016 11:03:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XhAChplHNv-0 for ; Fri, 12 Aug 2016 11:03: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 for ; Fri, 12 Aug 2016 11:03:06 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CF37200A3 for ; Fri, 12 Aug 2016 11:03:06 +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 sviy5G9utc2L; Fri, 12 Aug 2016 11:03:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 041662009D; Fri, 12 Aug 2016 11:03:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5CB53C19421; Fri, 12 Aug 2016 11:03:05 +0200 (CEST) Date: Fri, 12 Aug 2016 11:03:05 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160812090305.GA5685@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] reporting the event that triggered the execution of a schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Aug 2016 09:03:12 -0000 Hi, during the last IETF, we discussed whether we should report the event that caused the execution of a schedule. I think this issue was initiall raised by Gert Grammel (according to the minutes). With the given model we have, I do not think we need to make any changes. The reason is that a schedule is bound to exactly one event source, that is, we do not support that multiple event sources trigger a common schedule. Since we report the schedule name in the result records, the event source is implicitely known. Hence I sugggest to do nothing (unless we want to allow multiple event sources to trigger schedules, which would be a more substantial change). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 12 02:40:47 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B693312D145 for ; Fri, 12 Aug 2016 02:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 5eX3m6so2GGP for ; Fri, 12 Aug 2016 02:40:44 -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 9F3E512B026 for ; Fri, 12 Aug 2016 02:40:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5DC38F11; Fri, 12 Aug 2016 11:40:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sgxuMd8uQapq; Fri, 12 Aug 2016 11:40:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 12 Aug 2016 11:40:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C88222009D; Fri, 12 Aug 2016 11:40:40 +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 Lfd4DKPeCx1D; Fri, 12 Aug 2016 11:40:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6AE72009B; Fri, 12 Aug 2016 11:40:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6EA163C19860; Fri, 12 Aug 2016 11:40:38 +0200 (CEST) Date: Fri, 12 Aug 2016 11:40:37 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20160812094035.GB5685@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "lmap@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA75254AD4@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA75254AD4@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Aug 2016 09:40:46 -0000 On Thu, Jul 28, 2016 at 04:29:32PM +0000, Romascanu, Dan (Dan) wrote: > A few (mostly) editorial and clarification comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/: Thanks Dan. See my response inline. > 1. Section 3, pag. 8: 'It should be clear that the top-level behavior of an MA is simply to execute Schedules.' - what does 'top-level behavior' exactly mean? I have changes this to: The primary function of an MA is to execute Schedules. > 2. Section 3.3.2, pag. 16, definition of ma-suppression-match - s/An optional and possibly empty unordered set of match pattern/ An optional and possibly empty unordered set of match patterns/ Added the plural s. > 3. Section 3.8.1, pag 34, definition of ma-channel-interface-name - 'If not present, the system will select a suitable interface.' - who is 'the system' here?' It is usually the IP stack - if you connect() a socket, the IP stack usually decides which interface it uses by looking at the routing table. This extra parameter only makes sense in very specific corner cases (e.g., you use link-local addresses or for whatever reason you want to try to overwrite the routing decision). I find 'system' a reasonable term here. Do you want to change it to 'operating system' or 'IP protocol stack implementation'? > 4. Section 3.9, pag. 36: 'A reporting task might also have a flag parameter'- capitalize Reporting Task for consistency Capitalized as suggested. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 12 04:09:27 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E21812D688 for ; Fri, 12 Aug 2016 04:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 JDQSOSHqd-03 for ; Fri, 12 Aug 2016 04:09:24 -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 14E6B12D9DD for ; Fri, 12 Aug 2016 04:09:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A99D9763 for ; Fri, 12 Aug 2016 13:09:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hZQm4cKFtCfY for ; Fri, 12 Aug 2016 13:09:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 12 Aug 2016 13:09:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB76C2009D for ; Fri, 12 Aug 2016 13:09:17 +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 TWyacJQiXlqK; Fri, 12 Aug 2016 13:09:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D47E22009B; Fri, 12 Aug 2016 13:09:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 20CF93C19CC3; Fri, 12 Aug 2016 13:09:16 +0200 (CEST) Date: Fri, 12 Aug 2016 13:09:15 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20160812110915.GC5685@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 12 Aug 2016 11:09:25 -0000 Hi, here is an attempt to resolve the discussion around option names. OLD While many of the Task Configuration Options are left to individual tasks to define, some common Options are used by multiple tasks and benefit from standardisation: o Channel is used to specify the details of an endpoint for Control or Reporting Task communications and is detailed elsewhere in this document. The common option name for specifying the channel is "channel". NEW The ma-option-obj is used to define Task Configuration Options. Task Configuration Options are generally task specific. For tasks associated with an entry in a registry, the registry may define well- known option names (e.g., the so-called parameters in the IPPM metric registry [I-D.ietf-ippm-metric-registry]). Control and Reporting Tasks need to know the Channel they are going to use. The common option name for specifying the channel is "channel" where the option's value refers to the name of an ma-channel-obj. My intention was to explain more clearly that some of the option names fall out of registries (e.g., the IPPM metric registry). I kept the definition of the well-known "channel" option name and I clarified that the value of this well-known option refers to the name of an ma-channel-obj. Personally, I would have preferred if we would not hard code any option names in the information model. I would rather have a simple LMAP task registry for (non-measurement) tasks that defines task specific parameters or options. This would give us the flexibility to define common non-measurement task options when we need them. But for the sake of wrapping this document up in a timely manner, I am willing to go along with the proposed text. That all said, I personally find the IPPM metry registry somewhat difficult to work with. I could envision an approach where we complement the IPPM metric registry with an LMAP task registry that simply defines LMAP tasks, their functionality, and their well-known options. For measurement tasks, this LMAP task registry would refer to the IPPM metric registry which has all the details for the differnet IPPM metrics. For non-measurement tasks, the LMAP task registry would provide the information necessary to use them in an interoperable manner, such as the channel name or the flag whether empty reports should be suppressed for report tasks. In essence, such an LMAP task registry would consist of - a URI - a short description - an optional reference to a metric registry - a list of well-known option names, each with a short description and this would give us a well-known URI for identifying lets say an LMAP reporting task that has well-known options and we would not need to hard-code anything in the information model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 12 12:22:25 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF11B12D8D0 for ; Fri, 12 Aug 2016 12:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8YviITVQqyGM for ; Fri, 12 Aug 2016 12:22:20 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4D112DA7D for ; Fri, 12 Aug 2016 12:22:20 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 813FBF662F2F7; Fri, 12 Aug 2016 19:22:16 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u7CJMIcc005981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Aug 2016 19:22:19 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u7CJMIAB031998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Aug 2016 19:22:18 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 12 Aug 2016 15:21:49 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquw Date: Fri, 12 Aug 2016 19:21:48 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> In-Reply-To: <20160812110915.GC5685@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 12 Aug 2016 19:22:22 -0000 Juergen, The text seems fine to me. As to the LMAP registry, I know in the BBF we also plan to have a registry = as well for some of the BBF specific tests and metrics. However we didn't t= hink we should "wrapper" or "reference" the IPPM registry entries as they w= ere suppose to be used directly in LMAP. I'm not sure why you would think t= hat would be needed? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, August 12, 2016 6:09 AM To: lmap@ietf.org Subject: [lmap] well known channel names Hi, here is an attempt to resolve the discussion around option names. OLD While many of the Task Configuration Options are left to individual tasks to define, some common Options are used by multiple tasks and benefit from standardisation: o Channel is used to specify the details of an endpoint for Control or Reporting Task communications and is detailed elsewhere in this document. The common option name for specifying the channel is "channel". NEW The ma-option-obj is used to define Task Configuration Options. Task Configuration Options are generally task specific. For tasks associated with an entry in a registry, the registry may define well- known option names (e.g., the so-called parameters in the IPPM metric registry [I-D.ietf-ippm-metric-registry]). Control and Reporting Tasks need to know the Channel they are going to use. The common option name for specifying the channel is "channel" where the option's value refers to the name of an ma-channel-obj. My intention was to explain more clearly that some of the option names fall= out of registries (e.g., the IPPM metric registry). I kept the definition = of the well-known "channel" option name and I clarified that the value of t= his well-known option refers to the name of an ma-channel-obj. Personally, I would have preferred if we would not hard code any option nam= es in the information model. I would rather have a simple LMAP task registr= y for (non-measurement) tasks that defines task specific parameters or opti= ons. This would give us the flexibility to define common non-measurement ta= sk options when we need them. But for the sake of wrapping this document up= in a timely manner, I am willing to go along with the proposed text. That all said, I personally find the IPPM metry registry somewhat difficult= to work with. I could envision an approach where we complement the IPPM me= tric registry with an LMAP task registry that simply defines LMAP tasks, th= eir functionality, and their well-known options. For measurement tasks, thi= s LMAP task registry would refer to the IPPM metric registry which has all = the details for the differnet IPPM metrics. For non-measurement tasks, the = LMAP task registry would provide the information necessary to use them in a= n interoperable manner, such as the channel name or the flag whether empty = reports should be suppressed for report tasks. In essence, such an LMAP tas= k registry would consist of - a URI - a short description - an optional reference to a metric registry - a list of well-known option names, each with a short description and this would give us a well-known URI for identifying lets say an LMAP re= porting task that has well-known options and we would not need to hard-code= anything in the information model. /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 Sun Aug 14 00:25:48 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1763A12B03D for ; Sun, 14 Aug 2016 00:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.167 X-Spam-Level: X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 QCxlThDn20s2 for ; Sun, 14 Aug 2016 00:25:46 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010F212B01E for ; Sun, 14 Aug 2016 00:25:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HyAQDlG7BX/yYyC4ddGwEBAYJ6LYFSB?= =?us-ascii?q?40mrAqBfYYdAoErOBQBAQEBAQEBAQEDWyeEXgEBAQEDEihLBAIBCA0BAwQBAQs?= =?us-ascii?q?UCQcyFAkIAgQBEggaiA8BpXqaXAEBAQEBAQEDAQEBAQEBAQEBAQEchiuETIRCg?= =?us-ascii?q?yqCLwWOG4sjAZkBhVeMN4N4HjaDem6FcwF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2HyAQDlG7BX/yYyC4ddGwEBAYJ6LYFSB40mrAqBfYYdAoE?= =?us-ascii?q?rOBQBAQEBAQEBAQEDWyeEXgEBAQEDEihLBAIBCA0BAwQBAQsUCQcyFAkIAgQBE?= =?us-ascii?q?ggaiA8BpXqaXAEBAQEBAQEDAQEBAQEBAQEBAQEchiuETIRCgyqCLwWOG4sjAZk?= =?us-ascii?q?BhVeMN4N4HjaDem6FcwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,519,1464667200"; d="scan'208";a="187795741" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Aug 2016 03:25:44 -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/AES256-SHA; 14 Aug 2016 03:25:44 -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.0294.000; Sun, 14 Aug 2016 09:25:42 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] reporting the event that triggered the execution of a schedule Thread-Index: AQHR9HhfL4b+HvG9tkWRS1FoXtBzN6BIEQ0Q Date: Sun, 14 Aug 2016 07:25:42 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7526A914@AZ-FFEXMB04.global.avaya.com> References: <20160812090305.GA5685@elstar.local> In-Reply-To: <20160812090305.GA5685@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] reporting the event that triggered the execution of a schedule X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Aug 2016 07:25:47 -0000 > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Friday, August 12, 2016 12:03 PM > To: lmap@ietf.org > Subject: [lmap] reporting the event that triggered the execution of a > schedule >=20 > Hi, >=20 > during the last IETF, we discussed whether we should report the event tha= t > caused the execution of a schedule. I think this issue was initiall raise= d by > Gert Grammel (according to the minutes). >=20 > With the given model we have, I do not think we need to make any changes. > The reason is that a schedule is bound to exactly one event source, that = is, > we do not support that multiple event sources trigger a common schedule. > Since we report the schedule name in the result records, the event source= is > implicitely known. Hence I sugggest to do nothing (unless we want to allo= w > multiple event sources to trigger schedules, which would be a more > substantial change). >=20 > /js >=20 OK with this proposal.=20 Dan (as contributor) From nobody Sun Aug 14 00:26:36 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5184C12B03D for ; Sun, 14 Aug 2016 00:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.167 X-Spam-Level: X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 Ik9OCHcLHO-i for ; Sun, 14 Aug 2016 00:26:32 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB3012B01E for ; Sun, 14 Aug 2016 00:26:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ElBQDlG7BX/yYyC4ddGwEBAYJ6LVZ8B?= =?us-ascii?q?40mmgcBkgKBfRyBdoQLAoErOBQBAQEBAQEBAQEDWyeDR1s8AQEBAQMSKEsEAgE?= =?us-ascii?q?IDQMBBAEBCxQJBzIUCQgCBAESCBqIDwGleppcAQEBAQEBAQMBAQEBAQEBAQEeh?= =?us-ascii?q?iuETIRCgyqCLwWOG4sjAYYdizGHM4VXjDeDeB42ghIcgUxuhXMBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2ElBQDlG7BX/yYyC4ddGwEBAYJ6LVZ8B40mmgcBkgKBfRy?= =?us-ascii?q?BdoQLAoErOBQBAQEBAQEBAQEDWyeDR1s8AQEBAQMSKEsEAgEIDQMBBAEBCxQJB?= =?us-ascii?q?zIUCQgCBAESCBqIDwGleppcAQEBAQEBAQMBAQEBAQEBAQEehiuETIRCgyqCLwW?= =?us-ascii?q?OG4sjAYYdizGHM4VXjDeDeB42ghIcgUxuhXMBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,519,1464667200"; d="scan'208";a="187795754" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Aug 2016 03:26:31 -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/AES256-SHA; 14 Aug 2016 03:26:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0294.000; Sun, 14 Aug 2016 09:26:28 +0200 From: "Romascanu, Dan (Dan)" To: "Carey, Timothy (Nokia - US)" , "Juergen Schoenwaelder" , "lmap@ietf.org" Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9IoAZJ+amvOPuk6lYzpxlyoBEKBFku8AgAJ+MLA= Date: Sun, 14 Aug 2016 07:26:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7526A926@AZ-FFEXMB04.global.avaya.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Aug 2016 07:26:34 -0000 OK with me as well.=20 Dan (as contributor) > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Nokia - US) > Sent: Friday, August 12, 2016 10:22 PM > To: Juergen Schoenwaelder; lmap@ietf.org > Subject: Re: [lmap] well known channel names >=20 > Juergen, >=20 > The text seems fine to me. >=20 > As to the LMAP registry, I know in the BBF we also plan to have a registr= y as > well for some of the BBF specific tests and metrics. However we didn't th= ink > we should "wrapper" or "reference" the IPPM registry entries as they were > suppose to be used directly in LMAP. I'm not sure why you would think tha= t > would be needed? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, August 12, 2016 6:09 AM > To: lmap@ietf.org > Subject: [lmap] well known channel names >=20 > Hi, >=20 > here is an attempt to resolve the discussion around option names. >=20 > OLD >=20 > While many of the Task Configuration Options are left to individual > tasks to define, some common Options are used by multiple tasks and > benefit from standardisation: >=20 > o Channel is used to specify the details of an endpoint for Control > or Reporting Task communications and is detailed elsewhere in this > document. The common option name for specifying the channel is > "channel". >=20 > NEW >=20 > The ma-option-obj is used to define Task Configuration Options. Task > Configuration Options are generally task specific. For tasks > associated with an entry in a registry, the registry may define well- > known option names (e.g., the so-called parameters in the IPPM metric > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > Tasks need to know the Channel they are going to use. The common > option name for specifying the channel is "channel" where the > option's value refers to the name of an ma-channel-obj. >=20 > My intention was to explain more clearly that some of the option names fa= ll > out of registries (e.g., the IPPM metric registry). I kept the definition= of the > well-known "channel" option name and I clarified that the value of this w= ell- > known option refers to the name of an ma-channel-obj. >=20 > Personally, I would have preferred if we would not hard code any option > names in the information model. I would rather have a simple LMAP task > registry for (non-measurement) tasks that defines task specific parameter= s > or options. This would give us the flexibility to define common non- > measurement task options when we need them. But for the sake of > wrapping this document up in a timely manner, I am willing to go along wi= th > the proposed text. >=20 > That all said, I personally find the IPPM metry registry somewhat difficu= lt to > work with. I could envision an approach where we complement the IPPM > metric registry with an LMAP task registry that simply defines LMAP tasks= , > their functionality, and their well-known options. For measurement tasks, > this LMAP task registry would refer to the IPPM metric registry which has= all > the details for the differnet IPPM metrics. For non-measurement tasks, th= e > LMAP task registry would provide the information necessary to use them in > an interoperable manner, such as the channel name or the flag whether > empty reports should be suppressed for report tasks. In essence, such an > LMAP task registry would consist of >=20 > - a URI > - a short description > - an optional reference to a metric registry > - a list of well-known option names, each with a short description >=20 > and this would give us a well-known URI for identifying lets say an LMAP > reporting task that has well-known options and we would not need to hard- > code anything in the information model. >=20 > /js >=20 From nobody Sun Aug 14 00:28:45 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B170A12B01E for ; Sun, 14 Aug 2016 00:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 Qe35RqwWV03t for ; Sun, 14 Aug 2016 00:28:42 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A30812B012 for ; Sun, 14 Aug 2016 00:28:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GxAQBSHbBX/xUHmMZeGgEBAQGCei1Wf?= =?us-ascii?q?AeNJql7gg+BfSSBboQLAoErOBQBAQEBAQEBAQEDWyeCUzk7AQEBAQEBASMCLw8?= =?us-ascii?q?tAQEBAQIBEig/BQcEAgEIDQECAQQBAQsUCQcyFAkIAgQOBQgaiAcIAQ2mKJpcA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIYrhEyEQoMqghIdBY4biyMBhh2LMYczhVe?= =?us-ascii?q?MN4N4HjaCRYE1boVzAX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2GxAQBSHbBX/xUHmMZeGgEBAQGCei1WfAeNJql7gg+BfSS?= =?us-ascii?q?BboQLAoErOBQBAQEBAQEBAQEDWyeCUzk7AQEBAQEBASMCLw8tAQEBAQIBEig/B?= =?us-ascii?q?QcEAgEIDQECAQQBAQsUCQcyFAkIAgQOBQgaiAcIAQ2mKJpcAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBHIYrhEyEQoMqghIdBY4biyMBhh2LMYczhVeMN4N4HjaCRYE1b?= =?us-ascii?q?oVzAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,519,1464667200"; d="scan'208";a="201009978" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Aug 2016 03:28:40 -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/AES256-SHA; 14 Aug 2016 03:28:40 -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.0294.000; Sun, 14 Aug 2016 09:28:38 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder Thread-Topic: [lmap] WGLC comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ Thread-Index: AQHR9H2bHKLLQENwxkShun538H1PzqBIEYZw Date: Sun, 14 Aug 2016 07:28:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7526A93F@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA75254AD4@AZ-FFEXMB04.global.avaya.com> <20160812094035.GB5685@elstar.local> In-Reply-To: <20160812094035.GB5685@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] WGLC comments for https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 14 Aug 2016 07:28:43 -0000 All suggestions are fine. For #3 - 'IP protocol stack implementation' seem= s most clear to me.=20 Thanks for addressing my comments.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, August 12, 2016 12:41 PM > To: Romascanu, Dan (Dan) > Cc: lmap@ietf.org > Subject: Re: [lmap] WGLC comments for > https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ > ...=20 =20 > Thanks Dan. See my response inline. >=20 > > 1. Section 3, pag. 8: 'It should be clear that the top-level beha= vior of an > MA is simply to execute Schedules.' - what does 'top-level behavior' exac= tly > mean? >=20 > I have changes this to: >=20 > The primary function of an MA is to execute Schedules. >=20 > > 2. Section 3.3.2, pag. 16, definition of ma-suppression-match - s= /An > optional and possibly empty unordered set of match pattern/ An optional > and possibly empty unordered set of match patterns/ >=20 > Added the plural s. >=20 > > 3. Section 3.8.1, pag 34, definition of ma-channel-interface-name= - 'If not > present, the system will select a suitable interface.' - who is 'the syst= em' > here?' >=20 > It is usually the IP stack - if you connect() a socket, the IP stack usua= lly > decides which interface it uses by looking at the routing table. This ext= ra > parameter only makes sense in very specific corner cases (e.g., you use l= ink- > local addresses or for whatever reason you want to try to overwrite the > routing decision). I find 'system' a reasonable term here. Do you want to > change it to 'operating system' > or 'IP protocol stack implementation'? >=20 > > 4. Section 3.9, pag. 36: 'A reporting task might also have a flag > parameter'- capitalize Reporting Task for consistency >=20 > Capitalized as suggested. >=20 > /js >=20 From nobody Mon Aug 15 05:54:11 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E1912DD6E for ; Mon, 15 Aug 2016 05:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=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 wA7QHGXxOAeg for ; Mon, 15 Aug 2016 05:54:07 -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 632DB12D9E1 for ; Mon, 15 Aug 2016 05:54:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C0D4CAF9; Mon, 15 Aug 2016 14:54:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id P-Nh0fYgAJ4y; Mon, 15 Aug 2016 14: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; Mon, 15 Aug 2016 14:54:03 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07AA82009D; Mon, 15 Aug 2016 14:54:03 +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 S4EuaR6kNxsW; Mon, 15 Aug 2016 14:54:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DB3C2009B; Mon, 15 Aug 2016 14:54:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A4BD43C1E0F9; Mon, 15 Aug 2016 14:54:00 +0200 (CEST) Date: Mon, 15 Aug 2016 14:53:59 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160815125359.GA17225@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 15 Aug 2016 12:54:10 -0000 Tim, I arrived at this conclusion because of two observations: (a) LMAP has tasks that are not measurement tasks (like a reporting task) that will benefit of having some knowledge about common options; the metric registry does not apply to these non-measurement tasks (unless we start introducing pseudo metrics). (b) We have been struggling with the question to what extend the IPPM metric registry is expected to drive automation (e.g, does the IPPM registry define LMAP option names and how parameters are encoded as LMAP option values). If there would be an LMAP task registry, then the IPPM registry could focus on the abstract definition of metrics while the LMAP task registry would provide the binding to LMAP tasks, that is, how concrete tasks name use options etc to control the parameters defined in IPPM metrics. The LMAP task metric would likely be read by tools while the IPPM metric would likely be read by code developers. For me, this started to look like a rather natural split of concerns. /js On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > The text seems fine to me. > > As to the LMAP registry, I know in the BBF we also plan to have a registry as well for some of the BBF specific tests and metrics. However we didn't think we should "wrapper" or "reference" the IPPM registry entries as they were suppose to be used directly in LMAP. I'm not sure why you would think that would be needed? > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, August 12, 2016 6:09 AM > To: lmap@ietf.org > Subject: [lmap] well known channel names > > Hi, > > here is an attempt to resolve the discussion around option names. > > OLD > > While many of the Task Configuration Options are left to individual > tasks to define, some common Options are used by multiple tasks and > benefit from standardisation: > > o Channel is used to specify the details of an endpoint for Control > or Reporting Task communications and is detailed elsewhere in this > document. The common option name for specifying the channel is > "channel". > > NEW > > The ma-option-obj is used to define Task Configuration Options. Task > Configuration Options are generally task specific. For tasks > associated with an entry in a registry, the registry may define well- > known option names (e.g., the so-called parameters in the IPPM metric > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > Tasks need to know the Channel they are going to use. The common > option name for specifying the channel is "channel" where the > option's value refers to the name of an ma-channel-obj. > > My intention was to explain more clearly that some of the option names fall out of registries (e.g., the IPPM metric registry). I kept the definition of the well-known "channel" option name and I clarified that the value of this well-known option refers to the name of an ma-channel-obj. > > Personally, I would have preferred if we would not hard code any option names in the information model. I would rather have a simple LMAP task registry for (non-measurement) tasks that defines task specific parameters or options. This would give us the flexibility to define common non-measurement task options when we need them. But for the sake of wrapping this document up in a timely manner, I am willing to go along with the proposed text. > > That all said, I personally find the IPPM metry registry somewhat difficult to work with. I could envision an approach where we complement the IPPM metric registry with an LMAP task registry that simply defines LMAP tasks, their functionality, and their well-known options. For measurement tasks, this LMAP task registry would refer to the IPPM metric registry which has all the details for the differnet IPPM metrics. For non-measurement tasks, the LMAP task registry would provide the information necessary to use them in an interoperable manner, such as the channel name or the flag whether empty reports should be suppressed for report tasks. In essence, such an LMAP task registry would consist of > > - a URI > - a short description > - an optional reference to a metric registry > - a list of well-known option names, each with a short description > > and this would give us a well-known URI for identifying lets say an LMAP reporting task that has well-known options and we would not need to hard-code anything in the information model. > > /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 SS00473517@techmahindra.com Thu Aug 18 13:38:22 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCCD12D1EA for ; Thu, 18 Aug 2016 13:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q59ymQ4LX9A4 for ; Thu, 18 Aug 2016 13:38:19 -0700 (PDT) Received: from MXMEG2.techmahindra.com (mxmeg2.techmahindra.com [119.151.17.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7900D12D091 for ; Thu, 18 Aug 2016 13:38:16 -0700 (PDT) Received: from HYDEXCHMBX006.TechMahindra.com (unknown [10.56.222.132]) by MXMEG2.techmahindra.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA) id 4f54_778e_1a7af55e_4210_401f_beb7_fc4badf357c4; Fri, 19 Aug 2016 01:55:24 +0530 Received: from HYDEXCHMBX006.TechMahindra.com (10.56.222.132) by HYDEXCHMBX006.TechMahindra.com (10.56.222.132) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 19 Aug 2016 02:08:06 +0530 Received: from HYDEXCHMBX006.TechMahindra.com ([fe80::8419:ab13:1dc0:93a0]) by HYDEXCHMBX006.TechMahindra.com ([fe80::8419:ab13:1dc0:93a0%18]) with mapi id 15.00.1130.005; Fri, 19 Aug 2016 02:08:06 +0530 From: Sandeep Shah2 To: "lmap@ietf.org" Thread-Topic: Question on LMAP Implementation Thread-Index: AdH5kGiW9fjgSJ/aS4aqela8MevTRg== Date: Thu, 18 Aug 2016 20:38:05 +0000 Message-ID: <62578d42cdca4a2fb586e2b829db7578@HYDEXCHMBX006.TechMahindra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.56.205.138] Content-Type: multipart/related; boundary="_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 14:29:37 -0700 Subject: [lmap] Question on LMAP Implementation X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:41:44 -0000 --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: multipart/alternative; boundary="_000_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_" --_000_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hello - I have a quick question, and I would very much appreciate your response. I would like to know if there are any vendors or entities who are develop= ing software product or opensource software for LMAP technology. Thank you very much in advance. [Description: Description: cid:image015.jpg@01D1E7FC.BB548B70] SANDEEP SHAH Customer Delivery Head/SDN-NFV-Cloud Plano, TX 847-708-1068 sandeep.shah2@techmahindra.com techmahindra.com We believe [Description: Description: Description: cid:image003.png@01D0A510.436B272= 0][Description: Description: Descri= ption: cid:image004.png@01D0A510.436B2720][Description: Description: Description: cid:image011.png@01D0A51D.= F8D493A0][Description: De= scription: Description: cid:image006.png@01D0A510.436B2720] [Description: Description: cid:image004.png@01D1E982.7E538C80] Innovation. Value Creation. Opensource. Automation. Next Generation Servi= ces =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D Disclaimer: This message and the information contained herein is proprie= tary and confidential and subject to the Tech Mahindra policy statement, = you may review the policy at http://www.techmahindra.com/Disclaimer.html = externally http://tim.techmahindra.com/tim/disclaimer.html internally wit= hin TechMahindra.=0D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D --_000_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0 ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPgo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4KPCEtLVtpZiAhbXNvXT48 c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQpvXDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9CndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9Cjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KQGZvbnQtZmFjZQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsKCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowaW47CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0 OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpibHVlOwoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOnB1cnBsZTsKCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5U ZXh0Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7CgltYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEx LjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsKCW1hcmdpbjowaW47CgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6OC4wcHQ7Cglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQpzcGFuLkVtYWlsU3R5bGUxNwoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LWNvbXBvc2U7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29sb3I6d2lu ZG93dGV4dDt9CnNwYW4uQmFsbG9vblRleHRDaGFyCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsKCW1zby1zdHlsZS1wcmlvcml0eTo5OTsKCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOwoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30Kc3Bhbi5QbGFp blRleHRDaGFyCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7Cgltc28tc3R5bGUt cHJpb3JpdHk6OTk7Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7Cglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQpAcGFnZSBX b3JkU2VjdGlvbjEKCXtzaXplOjguNWluIDExLjBpbjsKCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPgo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IZWxsbyAtIDxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZlIGEgcXVpY2sgcXVlc3Rpb24sIGFuZCBJIHdvdWxkIHZl cnkgbXVjaCBhcHByZWNpYXRlIHlvdXIgcmVzcG9uc2UuPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5JIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGVyZSBhcmUgYW55IHZlbmRvcnMgb3IgZW50 aXRpZXMgd2hvIGFyZSBkZXZlbG9waW5nIHNvZnR3YXJlIHByb2R1Y3Qgb3Igb3BlbnNvdXJjZSBz b2Z0d2FyZSBmb3IgTE1BUCB0ZWNobm9sb2d5LjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNlLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNl OmNvbGxhcHNlIj4KPHRib2R5Pgo8dHIgc3R5bGU9ImhlaWdodDouMWluIj4KPHRkIHJvd3NwYW49 IjYiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gLjFpbiAwaW4gMGluO2hlaWdodDou MWluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO21zby1saW5lLWhlaWdodC1hbHQ6Ny4ycHQiPgo8YSBocmVmPSJodHRwOi8vd3d3 LnRlY2htYWhpbmRyYS5jb20vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQwNDA0 MDt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDUiIGhlaWdo dD0iODkiIGlkPSJQaWN0dXJlX3gwMDIwXzYiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQxRjk2 Ni44MDU0REE0MCIgYWx0PSJEZXNjcmlwdGlvbjogRGVzY3JpcHRpb246IGNpZDppbWFnZTAxNS5q cGdAMDFEMUU3RkMuQkI1NDhCNzAiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM0MDQwNDAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHJvd3NwYW49 IjYiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gLjFpbiAwaW4gMGluO2hlaWdodDou MWluIj48L3RkPgo8dGQgc3R5bGU9InBhZGRpbmc6MGluIC4xaW4gMGluIDBpbjtoZWlnaHQ6LjFp biI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjcuMnB0 Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPlNBTkRFRVAgU0hB SDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+CjwvdGQ+CjwvdHI+Cjx0ciBzdHlsZT0iaGVpZ2h0Oi4x aW4iPgo8dGQgc3R5bGU9InBhZGRpbmc6MGluIC4xaW4gMGluIDBpbjtoZWlnaHQ6LjFpbiI+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMTUlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDA0MDQwIj5DdXN0b21lciBEZWxp dmVyeSBIZWFkL1NETi1ORlYtQ2xvdWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtsaW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQwNDA0MCI+PG86cD48L286cD48L3NwYW4+PC9wPgo8L3Rk Pgo8L3RyPgo8dHIgc3R5bGU9ImhlaWdodDouMWluIj4KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAu MWluIDBpbiAwaW47aGVpZ2h0Oi4xaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LWxpbmUtaGVpZ2h0LWFsdDo3LjJwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0 MDQwNDAiPlBsYW5vLCBUWDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQw NDA0MCI+PG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8L3RyPgo8dHIgc3R5bGU9ImhlaWdo dDouMWluIj4KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAuMWluIDBpbiAwaW47aGVpZ2h0Oi4xaW4i Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDo3LjJwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjg0Ny03MDgtMTA2ODwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQwNDA0MCI+PG86cD48L286cD48L3Nw YW4+PC9wPgo8L3RkPgo8L3RyPgo8dHIgc3R5bGU9ImhlaWdodDouMWluIj4KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAuMWluIDBpbiAwaW47aGVpZ2h0Oi4xaW4iPgo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDts aW5lLWhlaWdodDoxMTUlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0ibWFpbHRvOnNhbmRlZXAuc2hhaDJA dGVjaG1haGluZHJhLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPnNhbmRlZXAuc2hhaDJA dGVjaG1haGluZHJhLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4K PC90ZD4KPC90cj4KPHRyIHN0eWxlPSJoZWlnaHQ6LjFpbiI+Cjx0ZCBzdHlsZT0icGFkZGluZzow aW4gLjFpbiAwaW4gMGluO2hlaWdodDouMWluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjExNSUiPjxhIGhyZWY9Imh0dHA6Ly93d3cudGVjaG1haGluZHJhLmNvbS8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDA7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnRlY2htYWhpbmRyYS5jb208L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KPC90ZD4KPC90cj4KPHRyIHN0eWxlPSJoZWlnaHQ6LjFpbiI+Cjx0ZCB2 YWxpZ249ImJvdHRvbSIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDouMWlu Ij4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjExNSUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPldlIGJlbGll dmU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtsaW5lLWhlaWdodDoxMTUlO2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzQwNDA0MCI+PG86cD48L286cD48L3NwYW4+PC9wPgo8L3RkPgo8dGQgc3R5bGU9InBhZGRpbmc6 MGluIDBpbiAwaW4gMGluO2hlaWdodDouMWluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjExNSUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAuMWlu IDBpbiAwaW47aGVpZ2h0Oi4xaW4iPgo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjQ2JSIgc3R5bGU9 IndpZHRoOjQ2LjElO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+Cjx0Ym9keT4KPHRyPgo8dGQg d2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4i Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTE1JSI+PGEgaHJlZj0i aHR0cDovL3d3dy5mYWNlYm9vay5jb20vdGVjaG1haGluZHJhIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDA0MDQwO3RleHQtZGVjb3JhdGlvbjpub25l Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI0IiBoZWlnaHQ9IjI0IiBpZD0iUGljdHVyZV94MDAy MF81IiBzcmM9ImNpZDppbWFnZTAwMi5wbmdAMDFEMUY5NjYuODA1NERBNDAiIGFsdD0iRGVzY3Jp cHRpb246IERlc2NyaXB0aW9uOiBEZXNjcmlwdGlvbjogY2lkOmltYWdlMDAzLnBuZ0AwMUQwQTUx MC40MzZCMjcyMCI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3Rl Y2hfbWFoaW5kcmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1 JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM0MDQwNDA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0i MjQiIGhlaWdodD0iMjQiIGlkPSJQaWN0dXJlX3gwMDIwXzQiIHNyYz0iY2lkOmltYWdlMDAzLnBu Z0AwMUQxRjk2Ni44MDU0REE0MCIgYWx0PSJEZXNjcmlwdGlvbjogRGVzY3JpcHRpb246IERlc2Ny aXB0aW9uOiBjaWQ6aW1hZ2UwMDQucG5nQDAxRDBBNTEwLjQzNkIyNzIwIj48L3NwYW4+PC9hPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55L3RlY2gtbWFoaW5kcmEiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDA7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjQiIGhlaWdodD0iMjQi IGlkPSJQaWN0dXJlX3gwMDIwXzMiIHNyYz0iY2lkOmltYWdlMDA0LnBuZ0AwMUQxRjk2Ni44MDU0 REE0MCIgYWx0PSJEZXNjcmlwdGlvbjogRGVzY3JpcHRpb246IERlc2NyaXB0aW9uOiBjaWQ6aW1h Z2UwMTEucG5nQDAxRDBBNTFELkY4RDQ5M0EwIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8v d3d3LnlvdXR1YmUuY29tL3VzZXIvVGVjaE1haGluZHJhMDkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0MDQwNDA7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjQiIGhlaWdodD0iMjQiIGlkPSJQaWN0dXJlX3gwMDIw XzIiIHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUQxRjk2Ni44MDU0REE0MCIgYWx0PSJEZXNjcmlw dGlvbjogRGVzY3JpcHRpb246IERlc2NyaXB0aW9uOiBjaWQ6aW1hZ2UwMDYucG5nQDAxRDBBNTEw LjQzNkIyNzIwIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1o ZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPC90cj4K PC90Ym9keT4KPC90YWJsZT4KPC90ZD4KPC90cj4KPHRyIHN0eWxlPSJoZWlnaHQ6LjFpbiI+Cjx0 ZCByb3dzcGFuPSIyIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu O2hlaWdodDouMWluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEx NSUiPjxhIGhyZWY9Imh0dHA6Ly9vbmxpbmUud3NqLmNvbS9hZC9pbnRoZWZ1dHVyZS8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1oZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVj b3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9Ijc2IiBoZWlnaHQ9IjE0IiBpZD0i UGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwNi5wbmdAMDFEMUY5NjYuODA1NERBNDAi IGFsdD0iRGVzY3JpcHRpb246IERlc2NyaXB0aW9uOiBjaWQ6aW1hZ2UwMDQucG5nQDAxRDFFOTgy LjdFNTM4QzgwIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bGluZS1o ZWlnaHQ6MTE1JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM0MDQwNDAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPC90ZD4KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6LjFpbiI+CjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdo dDoxMTUlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2xpbmUtaGVpZ2h0OjExNSU7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NDA0MDQwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+Cjx0ZCBzdHlsZT0icGFk ZGluZzowaW4gLjFpbiAwaW4gMGluO2hlaWdodDouMWluIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO21zby1saW5lLWhlaWdodC1h bHQ6Ny4ycHQiPgo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQwNDA0MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPgo8L3RkPgo8L3RyPgo8dHIgc3R5bGU9ImhlaWdodDouMWlu Ij4KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6LjFpbiI+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjts aW5lLWhlaWdodDoxMTUlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2xpbmUtaGVpZ2h0 OjExNSU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojNDA0MDQwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjwvdGQ+Cjx0ZCBz dHlsZT0icGFkZGluZzowaW4gLjFpbiAwaW4gMGluO2hlaWdodDouMWluIj48L3RkPgo8L3RyPgo8 L3Rib2R5Pgo8L3RhYmxlPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPklubm92YXRpb24uIFZhbHVlIENyZWF0aW9uLiBPcGVuc291cmNlLiBBdXRvbWF0 aW9uLiBOZXh0IEdlbmVyYXRpb24gU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+Cgo8RElWPjxQ PjxIUj4KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxCUj4KRGlzY2xhaW1lcjogIFRoaXMgbWVzc2FnZSBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvcHJpZXRhcnkgYW5kIGNvbmZpZGVudGlh bCBhbmQgc3ViamVjdCB0byB0aGUgVGVjaCBNYWhpbmRyYSBwb2xpY3kgc3RhdGVtZW50LCB5b3Ug bWF5IHJldmlldyB0aGUgcG9saWN5IGF0IGh0dHA6Ly93d3cudGVjaG1haGluZHJhLmNvbS9EaXNj bGFpbWVyLmh0bWwgZXh0ZXJuYWxseSBodHRwOi8vdGltLnRlY2htYWhpbmRyYS5jb20vdGltL2Rp c2NsYWltZXIuaHRtbCBpbnRlcm5hbGx5IHdpdGhpbiBUZWNoTWFoaW5kcmEuPEJSPgo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PEJSPgoKPC9QPjwvRElWPgo8L2JvZHk+CjwvaHRtbD4K --_000_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_-- --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2034; creation-date="Thu, 18 Aug 2016 20:38:01 GMT"; modification-date="Thu, 18 Aug 2016 20:38:01 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABZAGkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDNooor yT9JCiiigAooooAKKKKACiiigBrfcP0r3Oz/AOPGD/rkv8q8Mb7h+le52f8Ax4wf9cl/lXVht2fO 598NP5/oeZ/ED/kaX/64J/WuarpfiB/yNL/9cE/rXNVhU+Nnr4H/AHan6IKKKKg6wooooAKKKKAC iiigAooooAa33D9K9zs/+PGD/rkv8q8Mb7h+le52f/HjB/1yX+VdWG3Z87n3w0/n+h5n8QP+Rpf/ AK4J/WuarpfiB/yNL/8AXBP61zVYVPjZ6+B/3an6IKKKKg6wooooAKKKKACiiigAooooAa33D9K9 zs/+PGD/AK5L/KvDG+4fpXudn/x4wf8AXJf5V1YbdnzuffDT+f6HmfxA/wCRpf8A64J/WuarpfiB /wAjS/8A1wT+tc1WFT42evgf92p+iCiprO1e9vIrWN0R5W2hpGwo+prdk8D6lFD5z3dgEIJB88/N j04qVGT2NalelTaU5WbOcop4hlIBEUmD/smkEUjEgRuSOoCnika3Q2ir1no93e293PGFVbSPzJA5 IJHtxVJkdMbkZc9MjFFmSpxbaT1QlFFFBYUUUUANb7h+le52f/HjB/1yX+VeGN9w/Svc7P8A48YP +uS/yrqw27Pnc++Gn8/0PM/iB/yNL/8AXBP61zVdL8QP+Rpf/rgn9a5qsKnxs9fA/wC7U/RBXQaz cQy+DtHgjmRpY9+9AeV+tUPDtvDd+IbG3uIxJFJLh1PQjBrrY10B4tZk/wCEfhH9lnGN/wDrOvtx 0qoRumY4usoVI+63bXS3W8er8y8moo6WUtvqcHkpbIDF9pWP5h1yCDmqMOqG9sNT+w6ja2N5Jebg zOACoAHBI56VnarpGn6jb6Lc2Noth9vDmQKC+0D2HWq934OSGyubiLUPNe2QO0T27Rkj8a1cpnnQ o4ey5pWbfVdn1tdbl+0up7JNZa+1S3ubp7RTHIrhgSM4A9/aqmpau+p+B4TeXSzXovOhwGC4PYdq t6p4X0u41uK0gvIbB5Ik8uARlt5PU+1VF8PLLpMFt5UaXDaibZrvqT14A9OKlqWqNoSw75ajet09 rW0t92nQ5aiumfwhbn7bHbazHNcWUbPJF5JGMe+aSPwzZ2i2E19qiLJdBJFtxESWBI4zmsvZyPQ+ u0ej/B+vY5qiuv1LwtZyahqdwLuPT7OzdFI8ssBkD/GqVr4XtrqCS4XVH8hWO2QWjkMB39qHTlew o46i481+3R9dTm2+4fpXudn/AMeMH/XJf5V4/wCINGOiXgtjOs6vEJFdRjIOe34V7BZ/8eMH/XNf 5V0YdNNpnj51ONSnTlHZ3/Q8z+IH/I0v/wBcE/rXNV0vxA/5Gl/+uCf1rmq56nxs9rA/7tT9EWdN vn03UYL6NFd4G3BWOAeMf1q6niGdI9VQW8ZGqHMnJ/d9en51k0VKk1sbTo05u8l/Sd/zN6z8W3Vk mnolrEwsEdEJY/OGHOadL4sZrS5t4tMgi+0psd/Ndjj8TXP0VXPLuZPCUG78v597/mbM/iW4uNdt tWa2iWS3UKsYY7Tj1qVfFtyqRqLSH93eG7HzHluePpzWDRS55dynhaLSXLsbEHiOeC+1G7W3jLag jI6knCZ9Ksf8JUJI7QXOj2lxJZoqRyOzAjHTpXP0UKcgeFot3a/P0/I3L3xTcX1tqED2sSC/dGch j8u3HT8qW18UvBpUGnS6fDcRQAhS0rqTnrnBrCoo55XuL6rR5eXl0369rfkX9d1iTW7lbiSCODy4 REEQkjAz6/WvYrP/AI8YP+uS/wAq8Nb7p+le5Wf/AB5Qf9c1/lXTh2222eHncIwp04xWiv8AoeZ/ ED/kaX/64J/WuarpfiB/yNL/APXBP61zVc9T42e1gf8Adqfoj//Z --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=1238; creation-date="Thu, 18 Aug 2016 20:38:02 GMT"; modification-date="Thu, 18 Aug 2016 20:38:02 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAARWSURBVEhL tVVfTFtlFD+39/bPeksYc5R/pVTDgsQ4sBkzUTBIZlw23ILTBxMSn/ai8qDxxZiQQDQ+GH0he5zB rGZL1IwYF0fGBjOEzbbAOsAFB3RQWhC2ttB/9/beFs/5tiKlHeOF09w//b7z/X7n/M73nSt0dXXB Xpqwl+CEvSuCzs7OQkmSDs8tzAk6nVGottmWu7u7J3YT3I4ECKzr7b3Qcv6H3nfLSstPxKSYYNAb +L8nJmdEscDR2PjaQH9///RORE8lsNvtrd9+9/1xWVLOyLJU6vU+2MRRFPVgQYHpyODQn0NW6/OD p0+39vb09ATyEeUlEMX97bOzc1/HYwlrIiEBxwEkk0l2qaoKPC/guyzwAn9Mrze8efnybxiP/ZOx sbHl7SRZBCiJ4eLPv74/P+v9JhSOVqhqCv03YGMD73izVlZCbW0NFBYWwtr6Onju3AWfz8fHnjtw huM5TUfH2Y6iorIA1gdXPLYsgtHR0aNqUv4qIUsVsixjpDxzoqi1Wi00N78BdvsrbDwajYJ37gEs LS1BOBQGk2hqm5ycjTY1lZ3FJXIOAe2UHy/8dHx+ft4iSxLwGg3z4VAfIhBFIxSbzQw8GAzCvXvT EEESrU4HGvRdx4xu/eWyDg7e2ATPygBTfbmwoOADKSFpMhGTLCQRkXCcBtLpFJPKPToO1wdu4Ewa 9Ho9CyQeT0AsHre9/VbLseHh4YGcDDwej2519ZGRIiRAAqInSVVUtB8aG1+HkhIzW/diTQ0oWHCn y4VZxECH8lFQpaUlVcHQ2ofokkswNT2nppWkkpElE4GiKGAymaC+rg5Eo8iGrVYLKEoSbjudsJFO szGe1wAeRrh/f+Zx4Z7Y/0VWGXaO0ZaMRiMwMTEFDQ12MBqNEAgEwOl0Qwyj12q3QOCuSypyStDg vt5OUF19SPfw0YoxHo8xecjoaTDoIRxeg6GbN1nkNlsVjI97wOV2s+KSpOROEuHhA3Nxscnrnckl sFhKFkLhoBsdW3ARv7UOpAJJkn4iB4GpKJ3eYEAginaDkeFBDNleqBrOS4A95R+O4y/t22doluUk n0rRIWN5sGILgsBA6J2izpwR8iBiURQhpaqzFYnEufw1wNESm/VawLvwO0rTRmCZiDMLaIyMCsr6 xxbDAq9bKy3nHCMj0lMJlr1eX119/XX/gv+dRX9AoCwoUkHgmcYez10s8BL4Fv2bGVC1aBtbLBWL rSdP9GHTyyLOaXZtp05dvHr1Wi2n4T5eWVmFSCTKCCibkVu3sxYTOcoSKS8vXXj1aMPnCB7evg1z CLBRBbFtfOkaPRAZH7tzIhgMHaZMEokEqwedZgI2s7ahCUUjsU+bGl+64nBcergdnP7nbddIsoZz X7zX3n7+X5//I7fTZV70+dNaLWaCP57TYtM7wh+qrvqjr6/P4XBcyYfNxnb8ov3icNCG/owcy8oO ZoFMTY4DXc+yXX2TnwWy0/yeE/wHz50A9BJhYgkAAAAASUVORK5CYII= --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=1268; creation-date="Thu, 18 Aug 2016 20:38:02 GMT"; modification-date="Thu, 18 Aug 2016 20:38:02 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR0SURBVEhL tZVtTFtlFMfPfWlve1scUFiLZhYQdMwxlrEIsrCYJUbmTIyRbbJB4uKmYV+IHxb9IgkNiR+MRMGY ZS7MjyKLUeKyZFmD7YQS3lpAIEwYUaCltKX0bbe0va3nucJcoWXyYU/zpL33Pvf8zsv/nLItLS3w NBf7NI0T27sCNDc3UwaDIbEbp54IqK+vV3d3dzOVlVVNQ0PDB06++VYiJAimjy62ds7M3GYR+HAn 4I6Ao0dfOT0wONjk8fhok/leRXZ2Nk2Mray4Tp0+U1HX1dUVLS0tNUxMTJjTQVICGhsbi69evVbR bxn4iudVGoVSAf5AALxer2RHJpNn8Lzy+IP5v8Dj9uq02r2fXLny8ThGs7AVlBLQ22u+TtFMZSQS kq+vrwPDMMBubGIgFhPB7/dLtiiKfpmi4WbPr7e68PL9JwI4VXbtyIh1v5yTyROJBESjUaBpWtrk OhKNAF6BUqmEUCiE9uIY2ZpiwDJYrtFqj4XW3H2PQ5IiqK2tffs38+/frDH0XkEQIEOtBgoNu1xu kMtlkMBPVmYmHKuqAqwHLCwugtPphNnZBxglfTBTrfzuTM2FD278cMOyCUkC2Mb/qIlEItooekk8 z9XmwvHqajCZzDA5OQUMy0D5kXI4ceI16f2yskMwNzcLdrudRAGCEC4ZnLRW46M0AJstqFQosIis BAg/DMNzeXlw7tx70N9vAYd9GYqKCh9lgKIAHI5lCAZDGCEHC0tL4uTUlC8PHUsZQSgkoHEO08Jg 8SgQwoKkHr3+eThZ8waEw2Fg2f+CjsViGME8ei6ASqWGRDxOF+gLDl66dOGZjo4OSQVp+4AARDGO kLDkDCkyz/NJIsF0gtvjlu6JYozAqZIDL13E+3fx1i/bAKgSHANxQLlgJDLSUDA8PAxFLxQmeb5J sdsdklxJVCwrI5CE3eG4q1KpplOmSJOVxcsVcghhTonHqAyYnp6BsbEJOHz4kNQPmyscXoe+Pgv4 fH5QYN3IWY7jqT9n7t9pa2u7nxKg1+c77I6ldUwNR14gL5K95vNJPbC5gsEgGI29YLXZpEiJM0R5 apXKW1xU5p+bm0tdZJ1Oc31h8e9TePDVQDAAGRkZKMsjUFhYIBVbxA52uV0wMmyFUatVMkwAZPG8 GmKieCc/P78nLWB0dNT5YnHxTwuLS+WoIDnxdHBoCGZR6wzmOYJjw+NZhQDCiGGyRVGUvpUKzrtv 37M9RqPx34G1sbap6Pz5uq+/+LJdgYr5DMeCBPF4PI+UxGKzkbRtLo7jMBLGi5xP6+rqunDgJSlt GwAPRPFEa06OjkZAk3PFmYmTE8c0dhVu0lzkJ0kX1kXUaHKWE1SiNbC2em2r8W0yfRx9+fKHn3d2 fj+OBl/HNLzjcDhjDENJSkY1Ubm52nhcFG/m6XS3zp5915zK+I6AjUh+xr/J3vb2b39c9fhirAKn XQwwRUqqZP+eeENDwxj5RzMYJpPSsmMNtp5EAz68Z9LrtUmP5ufnIZ3XuwKkde1/PvgH6E7xWfDh 7VsAAAAASUVORK5CYII= --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=1191; creation-date="Thu, 18 Aug 2016 20:38:03 GMT"; modification-date="Thu, 18 Aug 2016 20:38:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAQnSURBVEhL zVVLbBNXFL0z9oztxD812HGQ7cbGAlIKgQQIXVQWosRq1EVRfxFim23VdtVuIiXLVqhSpYolqkSr VAqNQDVpsOWWIoIENMUiRfk4doo/seMEOx47jufb+yYBNWCTFRJv/DSfN3POveee+6wdGhqClzm0 LxOcYL86BB0dHS0+n69Xp9O1NpmasqvLq6FgMLi6kwIvzGBwcFA7Nvar/9/ko5PR6LS7WOACRnOz hef5QjqViRw71pPcs8dzbWRk5M9GRA0Jzp370Hd57OpnszOzpyRZ3AcURcXiC6AoCsFysCx7diGe UFLp9Onm5uYvKpXKjXokdQkGBgba/7hx8+tUKn0mn88DTVNgMOgJh0pAzrIsQzKZpFCyLlGSztNA f86y1M1nSeoSXL8ePpvNLp+RZAm6ug7D0tISzixoNBp1EhJBEFSiWq0GDMN2m8zmb7qPHPx0cnLy zv9JniNweBx744nFvnKpAgcOdEBv7ykIhyKQiC8CwzKb3yIwsqiXDMNskspyz9xc7OP+/v77WBP+ Cck2Aiwqdf7b796TROUETQOIogi53DKgvuB+3QVerxdWVlagyWAAu92GEqUgthBXs1hbWwOTsamv UChcQ/BIXYKlQmG/y+n8pPi4oEGngNVqBbfLBQ+m/wGj2Qx97wZUacgka9XqBvw2PgF37t7Fmogg iGL7TCzW3lCiR/G4tVpd3w0YvSTJwGL6FosV9KwOBEkCdAuQokciv4MFCQK9p6HnxHGYm58HrlyG 1ccFPpVO8maj8SnHNomqHAc8pkttHcQpEgKrzoHNwt67NwXjEyFwOV1wuLMTjAjGYgCKUgYJJa1w VWhI8JrJVNQyTBpBnWohN39bdaWxkArKUlWLSmtoEFBGDZ4VPEgwer2eanU48BOpfgaHurtnRi5f +UkQhU5Wx+pVW2oRjMZJHIMuwgYDmqJBiy7Ad1QXoaXU7Ow2G+PzeRi0an2C4eFhxWbblV3HKDmu DMVCEeLxBBTRIWRg56JbSioJNhckU2mVgIAzDKpNUVGvd1+0IQEBCQTeuR0KRa5wHPcBWlCbwQYj NiWDNNzGxoaquyDwEAqFURoFKutVcLvd0NrmCF66dPGvFzba6OhoUqezfmWxWjyCIB7P5XJqlKTQ pVJJvWZRKuKyfH5FfW632aFtd9svR9/q+fnB/altu0XdraJWKyb8/pM/Tv0dVQS+dhQxNKSIBmyw J0NRRPUeG0622W1XHfZdX168cGF+GzreNNxN/f63v5+dnQ/zgukjdMv7SLK3VuPlrd2UANNaLTPr aGsdf/ON/T9g5s+BE7KGBFhw4rWHOIecHk84vZg5xJXWUBha3YQ87W724JHOqYlg8PbMw+lnA6/v okZvpRKJW7h2q6XF+vSVTCYFZO40Xp3/5J0ibbT+H9vo7kmsDnlaAAAAAElFTkSuQmCC --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=1176; creation-date="Thu, 18 Aug 2016 20:38:04 GMT"; modification-date="Thu, 18 Aug 2016 20:38:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAQYSURBVEhL tVVtaFtVGH7vR3JvcpPOJLa2TZYs0DpSaZ2CijDmF+jAsR+uwwrZLwXZ3yoq/gi0CIJYEP+I24r+ s246EaVtWlPT0iaTdrM262LS0O8kTWVJ23T5uvnwvLckmiVp+6cHDiH3nPM87/O873sO29PTA0c5 2KMER+xDE3xss7UHV1YeIycok94029vb+89hgtuXoLu722wfHT19e/pP9fWB799WCYKRohjqtxHn UDZLjXd2Xoh0dLSNErJULbKaBIFAwHDlSv8XvKB8BShg73rmOZqmJRwxI1oFlXBx5vZMfNLl+uz+ ffeXOt3z6WokFQQ2m03udrs/yIiFl0LhjZc5joN8Pg+iKAJFURIGy7KQTqe5paUlLpFMfmRpe+PZ 18+f++6bq1dvPkxSQdDX19dMUbLLCgXfLIoZyGTSUCgUyMyTSYFcLpeIstmshMXQjDaZTHUO/jq4 G+S4QX06XWZXGYHVajX+ePOXzzcj4UaMMpfLgUqlghfOnJGIJqemIBqNgVKpBJlMJiljGBpCoTCQ gM6dbmn1Xbr01tckJ7GikjKC5ZW193lefgEjxKjRFpVKgPb2NtDpdGA4bgCn0wl+f4AQZgioQtpH 06go9yjJ0Ydzc3MBAv5DVYLpmWmdKKL0Qslv3Ih2IOkTbRZobmoEt/sPcLlvwdbWlqSGYRhJbTAU 4mPbMdX/81CuYHk5rtXqyIH/Pu/5Xyid0Wg0cPbsq2A2m/fULCwQq1i0iBDGcmura2J9/SOl/SWk ri7rm/YR+/nV1VUpomLFVCs9LFeL5SQYDHoYGraD23ULLap6pkRA03njsWN1GpSKAPsRFElRGRYu VtiBjdbS0vLVtf5vnyGeXkSS/QZWj8+3AMPDw7C2vg4cz0uqkVAm22vGiiST0trVajWZXC6PXhIV TFWOGEmsi1iCid7e3gJsRFSMhUDyo2hqrOej0WglAX4xGY0/352/9yIB1xctwl85AcHh8/nBMTYG 3r/9pMFoEASh3MpC/vcTJ/QzNQl8Pu8NrU7z7oPdhD4ejxO5LCQSCbg37wUxK8Lk5BREIpvAE0uw 0Yr9gpY1NDRAnVo1dOeO56+aZYoLBmPTJ37vopFlZa34P5lMgn1kFNKksUQyBUFZsg+B0XfsBV7B 3Xj8ZOtPGxuh6jkofvV6vE6OE95RKhTXgFK07uzskIvtgdQb2LnFqNFzvJfUajVwcu66nGXemxgf X384cVWvawI4YbFYLocjm92pVPq5ujq1LpXKEHAsSZBIMGoKKJ9Bbxgzm49/6nA4KsCRrOZ74PV6 HWTd8fRTp7r8gcBrsfBGgSSftDWxhbw6pzqejJtMpn6Xa2J2cdF/cB/U2uHxzA6QtYGGem3ZlmBw BXAeNA79Jh8EVGv9yAn+BU9dwajfdUElAAAAAElFTkSuQmCC --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=2153; creation-date="Thu, 18 Aug 2016 20:38:04 GMT"; modification-date="Thu, 18 Aug 2016 20:38:04 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEwAAAAOCAYAAACFB/pMAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAfpSURBVFhH pVh9jFTVFT/3vjtvZ/ZjYFgoQdLGGkNsoqnYJmiMf5S2Vtetbf2DNum2KxZKXUbZNCKFBDe7iSQV SbEM6koNrFmpmCZSWhZdEYPaLDVpIaVB20SgQncpws7uzu7OzHv33dvfeTOzXzO7YrybO++++3Hu Ob/7O+eet6q9vZ06OjoOBEHQifYx1BeMMW14DrS1tdUR0R9QV9nEt2IDlHZ9pX5XJ5yVaT+/NBcl XavVRUUiqsli2vQi8Ipea4h2SSHWSUtVUSEpb4OVLyYb3m5O9fw8IVXniAnIkL2EuT0xIR/KWVMu rCi6Rjhi3JojluwI9PghZNMYmff3rb93BU95MNVzplrIrzgkKENBNwTdWE3y9ixrUSwYsxEhTuWt eXpvsmE/d0OXLfUy8uSg8cvs4I75QtEQ6T1q5ijA+roQ4iD6WQFdHMe+ieFsNLs4os3++VJ9e8QN mlRdIkXpdMUNpnYCOOxj8RD4m1YEvxf7wuaUdkW5k+N2cq2dJjacEv4UMBIkp4sKoEsVieWLpfsy gLqzK9mwng92hm5l+1trAVt5+QBdy8GwLajbwDKWIztab86uTn0sfa1OXBTex8LSGpXJgH02YJ1Y t1qwpwq1VHgh+sWQ1QrqzMqa4nwWEVsgFYFBIV+HjQ7lchusIbCPwCoaDbw4xA5/6kkVJsRLMkvz Awgctppy1ieMtTSlep93SOZrZISZXlFsHaAaDLzaSoC5QPLHWLUbgJ3GkykUoqC0huU6lzfO36NS fl9o/SUcroehmjoYM2btq2NWHyvtiEUCBrPNeZdoDZCdtQiycbjZa1esPp4zoUvGAHgHXKcObIDs 4A241Wvj0sCzxXlIXlvgUWUDEQLCc5Qkf3XZ6qUeXGfiIAXd5pJY6+MU2XUd8lfBEbvTxsuOGD3p u1O09SQ5APV0JcCimPeJ4zjrENcOo32BDea1WkUjeNRXUbDSs/YdrfSHEa2qeKwaW49b/+C+ZMPv Z6KyemfvnZGIkYGdnWQYqXa16etsvYf3Cwvi0SYYVMdxD6z7C2R3To4dfrjkv5VOoeRee5P3HJo5 /sjOQ7FsJPITZUUMhwTAxPyu5L3/wjyuc5YSYDHMcoozGbCFW7duPQWGPQO2PYl374mud+MDigLP 6O8ukdXx/5jxPRRLZGwmE7JvBJ4JXmzYsPuNb6SFf/KllsbnSjsbpV07M5CUq2VJKdYjLE07D8Xx HspmmBnQaUssyDtH0DF8OKBi87M9j1cbuSxLpdMylFHOV3HyMTAsFAnQTq1OHdmFvhvgLiHD5klH Isgf72ppeGrqviFgYNPbYNNH3FZKvQfPG+I24tcOgDYCNseo8c3sktf/3W+G18YCE/TGPf3HtJeF UQVxfAvVSLlinnRXDAfBm+iaAKwcm8/fA6zmjImh1dJKmP+zBY5axnGxUByCd9AoDpjj4RXjH4/r +IGMymxPSDeBGzqcNQ+xdFj7/DIdMKQU3WDROEBbvn379lcBzjlM4rjEgCXwQIClcZESjyEe3FJQ hP7RvrUt8/jO3vjlohrFAB8mETixucLV50frM0iA2/oMkF8kGG7I8FLhyylng0uBvtK4q/W+Ubi/ +2m3JG+rYrHYgXw+/xRSiQNof5DNZveg/yRqP+pC1FbUTmHF99wq90Uj5QUp5TgvTlOukDGgROAf yGvODlEwgNe/TbOJnafo8EwLgB4CCn+bCey16FwGF/KByUBdbBcECXDB9iFcjOcFAoYlviDrXSGW BQDNETIRoSVffKKt7cMLi25/ZdD6i3xToJgRxrFSvDNzM7Vx48Y/bdu2rRmg9SSTyY/AOOSmyu3r 63P5Cffk65v3H8zlcu/hyQwsucOEgXHpAEC947ctdz9bZpEs5Di8KIRXEsdJtrJqCkKzX3llAsOO ifiGa3Mi9iF5ifJmDt8IoFPXI/fhNp0siI2LA6XOShLVuNmrrjrBox3t7Q9jxprK20zvLQV9vv1q ikPcfv7o0aMMVC0q34LZYvsgnnmw8b94NiQoGlyeyG0BgIHjVyiw7DxiHAKKQA6Cgzb0aySMX4NN a0fxotAIrBjKan3pWpTmOQDlHJhCSAP4lrt59e4jOyDaxVfH9RxPazlhEHRxprzu1vv/h71fR1B/ IIMvDKQzq37U9nKrWpS46QtK3XVVl3L1wspSVlkLLUdI/7OSgR5YtQlzOYG9AfUFVGbEGGoT6nnQ PHQluCQcbaoIU9Gl8Plx7sHUkcMLZaRxwOQJnze3Igm9lcHiILvUcelS4O2HMSPXCpgg1YXAvYFD AQ5BJoT6JTMYSXIYn4YAJFTrrnyAsguR9gE+vHpHLRhcVP8dsP36WnKfme0yrxURGgn0KxUZgU36 i9+SzC7Wg4E20Wj07ObNmwev1aip8yLab0krcdN1surGNIwahEGcXy2VLl023glf6y2fRe7e5N0n f5r682P10n26mjP3kC2Fbz7+qLgqzPruXzScqSTTr6vpHcpk+vH1cB1fBpbMOsTlt0aNR2kGukIp fDfZsdkAY7fkUnryrVnned4xxDh2yX7kaT+Y6ZJzGbyn9f4LiB+3wZ5HYV8T3PDLmH8GwO09/Uni uffb76isaVEoUqqyDPylZOMOfNacqCXTCgf8phDW5K09mvHFb7pbG/46mz7dzXflmlOH97kkN+FC 4H3vsIHRGWk9wIcCb0aZuh7/XIC3k/d/rHGD0M2Lh5wAAAAASUVORK5CYII= --_009_62578d42cdca4a2fb586e2b829db7578HYDEXCHMBX006TechMahind_-- From nobody Fri Aug 19 11:48:40 2016 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC2112D65E; Fri, 19 Aug 2016 11:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147163251483.24227.13691316295708679004.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 11:48:34 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-11.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:48:35 -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 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-11.txt Pages : 51 Date : 2016-08-19 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 Measurement Agent 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 Measurement Agent 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: https://tools.ietf.org/html/draft-ietf-lmap-information-model-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-11 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 Sat Aug 20 10:17:52 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99FE12D13F for ; Sat, 20 Aug 2016 10:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xu8jEuM9Lmqr for ; Sat, 20 Aug 2016 10:17:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B1F12D13D for ; Sat, 20 Aug 2016 10:17:48 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 9BBCD593C02F2 for ; Sat, 20 Aug 2016 17:17:44 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u7KHHle7002923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 20 Aug 2016 17:17:47 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u7KHHlbk029419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Aug 2016 17:17:47 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 20 Aug 2016 13:17:47 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Draft 11 - minor edits Thread-Index: AdH7BsSfu4zkVmR7RO6HfCJrzkYn9w== Date: Sat, 20 Aug 2016 17:17:48 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A729EEE@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A729EEEUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Draft 11 - minor edits X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Aug 2016 17:17:51 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A729EEEUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I was going through Information Model draft 11 and found the following item= s (nothing big): 1) Typo (triggerent) ma-report-result-event-time: The date and time of the event that triggerent the schedule of the action that produced the reported result values. The date and time does not include any added randomization. 2) ma-status-suppression-obj The elements refer to ma-status-schedule-... not ma-status-supression-... --_000_9966516C6EB5FC4381E05BF80AA55F77012A729EEEUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I was going through Information Model draft 11 and f= ound the following items (nothing big):

 

1) Typo (triggerent)

 

ma-report-result-event-time: The dat= e and time of the event that

triggerent the schedule of the actio= n

that produced the reported result

values. The date and time does not

include any added randomization.

 

2) ma-status-suppression-obj

The elements refer to

ma-status-schedule-… not ma-status-supression-= …

 

--_000_9966516C6EB5FC4381E05BF80AA55F77012A729EEEUS70UWXCHMBA0_-- From nobody Sat Aug 20 10:34:29 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEFD128874 for ; Sat, 20 Aug 2016 10:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.02 X-Spam-Level: X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cef4TAAHnNVd for ; Sat, 20 Aug 2016 10:34:25 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A028512D0B3 for ; Sat, 20 Aug 2016 10:34:25 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 7733649663774 for ; Sat, 20 Aug 2016 17:34:21 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u7KHYObl003743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 20 Aug 2016 17:34:24 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u7KHYO6O025105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Aug 2016 17:34:24 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 20 Aug 2016 13:34:24 -0400 From: "Carey, Timothy (Nokia - US)" To: "lmap@ietf.org" Thread-Topic: Information Model draft 11 - Schedule options Thread-Index: AdH7CRbfzsYBOhUhTLOJ5rCOR1KaPg== Date: Sat, 20 Aug 2016 17:34:25 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A729F1B@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A729F1BUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Information Model draft 11 - Schedule options X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 20 Aug 2016 17:34:27 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A729F1BUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, The draft references Schedule options in several places - but I didn't see = it in the model. I think you meant action options. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A729F1BUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

The draft references Schedule options in several pla= ces – but I didn’t see it in the model. I think you meant actio= n options.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A729F1BUS70UWXCHMBA0_-- From nobody Sun Aug 21 17:58:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E886112D119 for ; Sun, 21 Aug 2016 17:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iM8LEJH-bx2u for ; Sun, 21 Aug 2016 17:58:11 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F1F12D1C0 for ; Sun, 21 Aug 2016 17:58:10 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id ECADE56D9F593; Mon, 22 Aug 2016 00:58:06 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u7M0w9P1002549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 00:58:09 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u7M0v9bD004957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 00:58:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 21 Aug 2016 20:57:53 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0A== Date: Mon, 22 Aug 2016 00:57:51 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> In-Reply-To: <20160815125359.GA17225@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 00:58:13 -0000 Juergen, Indeed in the BBF we are thinking about the same thing (having own own regi= stry) for non-measurement related tasks and diagnostic tasks that are not s= trictly associated with a metric (e.g., HTTP Upload). These should be new charter items IMHO. I did think though IPPM would define the metrics sufficient enough that the= y would be self describing in that that they can be used directly as LMAP a= ctions (including the actual test ala ICMP Ping) to run. Looking at ietf-ippm-initial-registry (at least the first one in section 4)= why do you think this is insufficient?=20 I would like to hear Al's thoughts if he believes another registry is neces= sary for implementing IPPM entries as testable tasks. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, August 15, 2016 7:54 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] well known channel names Tim, I arrived at this conclusion because of two observations: (a) LMAP has tasks that are not measurement tasks (like a reporting task) that will benefit of having some knowledge about common options; the metric registry does not apply to these non-measurement tasks (unless we start introducing pseudo metrics). (b) We have been struggling with the question to what extend the IPPM metric registry is expected to drive automation (e.g, does the IPPM registry define LMAP option names and how parameters are encoded as LMAP option values). If there would be an LMAP task registry, then the IPPM registry could focus= on the abstract definition of metrics while the LMAP task registry would p= rovide the binding to LMAP tasks, that is, how concrete tasks name use opti= ons etc to control the parameters defined in IPPM metrics. The LMAP task me= tric would likely be read by tools while the IPPM metric would likely be re= ad by code developers. For me, this started to look like a rather natural s= plit of concerns. /js On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > The text seems fine to me. >=20 > As to the LMAP registry, I know in the BBF we also plan to have a registr= y as well for some of the BBF specific tests and metrics. However we didn't= think we should "wrapper" or "reference" the IPPM registry entries as they= were suppose to be used directly in LMAP. I'm not sure why you would think= that would be needed? >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, August 12, 2016 6:09 AM > To: lmap@ietf.org > Subject: [lmap] well known channel names >=20 > Hi, >=20 > here is an attempt to resolve the discussion around option names. >=20 > OLD >=20 > While many of the Task Configuration Options are left to individual > tasks to define, some common Options are used by multiple tasks and > benefit from standardisation: >=20 > o Channel is used to specify the details of an endpoint for Control > or Reporting Task communications and is detailed elsewhere in this > document. The common option name for specifying the channel is > "channel". >=20 > NEW >=20 > The ma-option-obj is used to define Task Configuration Options. Task > Configuration Options are generally task specific. For tasks > associated with an entry in a registry, the registry may define well- > known option names (e.g., the so-called parameters in the IPPM metric > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > Tasks need to know the Channel they are going to use. The common > option name for specifying the channel is "channel" where the > option's value refers to the name of an ma-channel-obj. >=20 > My intention was to explain more clearly that some of the option names fa= ll out of registries (e.g., the IPPM metric registry). I kept the definitio= n of the well-known "channel" option name and I clarified that the value of= this well-known option refers to the name of an ma-channel-obj. >=20 > Personally, I would have preferred if we would not hard code any option n= ames in the information model. I would rather have a simple LMAP task regis= try for (non-measurement) tasks that defines task specific parameters or op= tions. This would give us the flexibility to define common non-measurement = task options when we need them. But for the sake of wrapping this document = up in a timely manner, I am willing to go along with the proposed text. >=20 > That all said, I personally find the IPPM metry registry somewhat=20 > difficult to work with. I could envision an approach where we=20 > complement the IPPM metric registry with an LMAP task registry that=20 > simply defines LMAP tasks, their functionality, and their well-known=20 > options. For measurement tasks, this LMAP task registry would refer to=20 > the IPPM metric registry which has all the details for the differnet=20 > IPPM metrics. For non-measurement tasks, the LMAP task registry would=20 > provide the information necessary to use them in an interoperable=20 > manner, such as the channel name or the flag whether empty reports=20 > should be suppressed for report tasks. In essence, such an LMAP task=20 > registry would consist of >=20 > - a URI > - a short description > - an optional reference to a metric registry > - a list of well-known option names, each with a short description >=20 > and this would give us a well-known URI for identifying lets say an LMAP = reporting task that has well-known options and we would not need to hard-co= de anything in the information model. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 >=20 --=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 Mon Aug 22 00:33:48 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8012B00C for ; Mon, 22 Aug 2016 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 XwNXeEDNUTFJ for ; Mon, 22 Aug 2016 00:33:45 -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 E96D312B049 for ; Mon, 22 Aug 2016 00:33:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2800170D; Mon, 22 Aug 2016 09:33:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GSYu-sfZQzWl; Mon, 22 Aug 2016 09:33:41 +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, 22 Aug 2016 09:33:42 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 841C9200AB; Mon, 22 Aug 2016 09:33:42 +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 sA1tM84vdc5I; Mon, 22 Aug 2016 09:33:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F0D5200A8; Mon, 22 Aug 2016 09:33:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD5CC3C29CEC; Mon, 22 Aug 2016 09:33:40 +0200 (CEST) Date: Mon, 22 Aug 2016 09:33:40 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160822073340.GB11509@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A729EEE@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A729EEE@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Draft 11 - minor edits X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 07:33:47 -0000 On Sat, Aug 20, 2016 at 05:17:48PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > I was going through Information Model draft 11 and found the following items (nothing big): > > 1) Typo (triggerent) > > ma-report-result-event-time: The date and time of the event that > > > triggerent the schedule of the action > > > that produced the reported result > > > values. The date and time does not > > > include any added randomization. Fixed. > 2) ma-status-suppression-obj > The elements refer to > ma-status-schedule-... not ma-status-supression-... I do not understand / find the issue. Can you please elaborate? /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 Aug 22 04:50:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8A312D17B for ; Mon, 22 Aug 2016 04:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EeLKl8SuAJ4M for ; Mon, 22 Aug 2016 04:50:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAA812D17A for ; Mon, 22 Aug 2016 04:50:02 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id CEC5C62F823F8; Mon, 22 Aug 2016 11:49:58 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u7MBo038028444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 11:50:00 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u7MBnxwx002590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 11:49:59 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 22 Aug 2016 07:49:59 -0400 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] Information Draft 11 - minor edits Thread-Index: AdH7BsSfu4zkVmR7RO6HfCJrzkYn9wBYkL8AAACA1sA= Date: Mon, 22 Aug 2016 11:49:58 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72A807@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77012A729EEE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160822073340.GB11509@elstar.local> In-Reply-To: <20160822073340.GB11509@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Draft 11 - minor edits X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 11:50:05 -0000 Juergen, Section 3.5.6 - in the description refers to the ma-status-schedule-name no= t ma-status-suppression-name; same for state attribute. 3.5.6. Definition of ma-status-suppression-obj object { string ma-status-suppression-name; string ma-status-suppression-state; } ma-status-suppression-obj; The ma-status-suppression-obj provides status information about that status of a suppression and consists of the following elements: ma-status-schedule-name: The name of the suppression this status object refers to. ma-status-schedule-state: The state of the suppression. The value 'enabled' indicates that the suppression is currently enabled. The value 'active indicates that the suppression is currently active. The value 'disabled' indicates that the suppression is currently disabled. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, August 22, 2016 2:34 AM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] Information Draft 11 - minor edits On Sat, Aug 20, 2016 at 05:17:48PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, >=20 > I was going through Information Model draft 11 and found the following it= ems (nothing big): >=20 > 1) Typo (triggerent) >=20 > ma-report-result-event-time: The date and time of the event that >=20 >=20 > triggerent the schedule of the action >=20 >=20 > that produced the reported result >=20 >=20 > values. The date and time does not >=20 >=20 > include any added randomization. Fixed. =20 > 2) ma-status-suppression-obj > The elements refer to > ma-status-schedule-... not ma-status-supression-... I do not understand / find the issue. Can you please elaborate? /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 Mon Aug 22 06:05:01 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39C12D0AD for ; Mon, 22 Aug 2016 06:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 X64ZbwffbuVl for ; Mon, 22 Aug 2016 06:04:57 -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 3D06312D0F7 for ; Mon, 22 Aug 2016 06:04:57 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 70C9A120FA2; Mon, 22 Aug 2016 09:17:52 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id A84E7E103F; Mon, 22 Aug 2016 09:04:52 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 22 Aug 2016 09:04:52 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Date: Mon, 22 Aug 2016 09:04:51 -0400 Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 13:05:00 -0000 One point that has come up in IPPM discussion: The Fixed and Run Tine Parameters in the registry all have names, but we may need to form a sub-registry to ensure that the names are used consistently (among different registry entries, and in their interpretation by other operations, e.g., as options in LMAP). IPPM agreed to continue with the IANA early review, and determine the efficacy of the parameter sub-registry in those conversations (on-going). Otherwise, I would like to hear what else is necessary (The IPPM RFCs and Metric entries are not abstract, IMO). regards, Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Sunday, August 21, 2016 8:58 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > Subject: RE: [lmap] well known channel names >=20 > Juergen, >=20 > Indeed in the BBF we are thinking about the same thing (having own own > registry) for non-measurement related tasks and diagnostic tasks that > are not strictly associated with a metric (e.g., HTTP Upload). > These should be new charter items IMHO. >=20 > I did think though IPPM would define the metrics sufficient enough that > they would be self describing in that that they can be used directly as > LMAP actions (including the actual test ala ICMP Ping) to run. >=20 > Looking at ietf-ippm-initial-registry (at least the first one in section > 4) why do you think this is insufficient? >=20 > I would like to hear Al's thoughts if he believes another registry is > necessary for implementing IPPM entries as testable tasks. >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, August 15, 2016 7:54 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] well known channel names >=20 > Tim, >=20 > I arrived at this conclusion because of two observations: >=20 > (a) LMAP has tasks that are not measurement tasks (like a reporting > task) that will benefit of having some knowledge about common > options; the metric registry does not apply to these > non-measurement tasks (unless we start introducing pseudo > metrics). >=20 > (b) We have been struggling with the question to what extend the IPPM > metric registry is expected to drive automation (e.g, does the > IPPM registry define LMAP option names and how parameters are > encoded as LMAP option values). >=20 > If there would be an LMAP task registry, then the IPPM registry could > focus on the abstract definition of metrics while the LMAP task registry > would provide the binding to LMAP tasks, that is, how concrete tasks > name use options etc to control the parameters defined in IPPM metrics. > The LMAP task metric would likely be read by tools while the IPPM metric > would likely be read by code developers. For me, this started to look > like a rather natural split of concerns. >=20 > /js >=20 > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) > wrote: > > Juergen, > > > > The text seems fine to me. > > > > As to the LMAP registry, I know in the BBF we also plan to have a > registry as well for some of the BBF specific tests and metrics. However > we didn't think we should "wrapper" or "reference" the IPPM registry > entries as they were suppose to be used directly in LMAP. I'm not sure > why you would think that would be needed? > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, August 12, 2016 6:09 AM > > To: lmap@ietf.org > > Subject: [lmap] well known channel names > > > > Hi, > > > > here is an attempt to resolve the discussion around option names. > > > > OLD > > > > While many of the Task Configuration Options are left to individual > > tasks to define, some common Options are used by multiple tasks and > > benefit from standardisation: > > > > o Channel is used to specify the details of an endpoint for > Control > > or Reporting Task communications and is detailed elsewhere in > this > > document. The common option name for specifying the channel is > > "channel". > > > > NEW > > > > The ma-option-obj is used to define Task Configuration Options. > Task > > Configuration Options are generally task specific. For tasks > > associated with an entry in a registry, the registry may define > well- > > known option names (e.g., the so-called parameters in the IPPM > metric > > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > > Tasks need to know the Channel they are going to use. The common > > option name for specifying the channel is "channel" where the > > option's value refers to the name of an ma-channel-obj. > > > > My intention was to explain more clearly that some of the option names > fall out of registries (e.g., the IPPM metric registry). I kept the > definition of the well-known "channel" option name and I clarified that > the value of this well-known option refers to the name of an ma-channel- > obj. > > > > Personally, I would have preferred if we would not hard code any > option names in the information model. I would rather have a simple LMAP > task registry for (non-measurement) tasks that defines task specific > parameters or options. This would give us the flexibility to define > common non-measurement task options when we need them. But for the sake > of wrapping this document up in a timely manner, I am willing to go > along with the proposed text. > > > > That all said, I personally find the IPPM metry registry somewhat > > difficult to work with. I could envision an approach where we > > complement the IPPM metric registry with an LMAP task registry that > > simply defines LMAP tasks, their functionality, and their well-known > > options. For measurement tasks, this LMAP task registry would refer to > > the IPPM metric registry which has all the details for the differnet > > IPPM metrics. For non-measurement tasks, the LMAP task registry would > > provide the information necessary to use them in an interoperable > > manner, such as the channel name or the flag whether empty reports > > should be suppressed for report tasks. In essence, such an LMAP task > > registry would consist of > > > > - a URI > > - a short description > > - an optional reference to a metric registry > > - a list of well-known option names, each with a short description > > > > and this would give us a well-known URI for identifying lets say an > LMAP reporting task that has well-known options and we would not need to > hard-code anything in the information model. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > >=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 Mon Aug 22 07:47:22 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982112D67A for ; Mon, 22 Aug 2016 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 e_oq69qVPqe0 for ; Mon, 22 Aug 2016 07:47:18 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7294312D672 for ; Mon, 22 Aug 2016 07:47:18 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 04DFFF59DA1E8; Mon, 22 Aug 2016 14:47:15 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u7MElHOO000857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 14:47:17 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u7MElGUZ009074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 14:47:17 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 22 Aug 2016 10:47:16 -0400 From: "Carey, Timothy (Nokia - US)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOA= Date: Mon, 22 Aug 2016 14:47:15 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 14:47:20 -0000 Al, I will say that when I looked at the first registry entry is was difficult = for me to understand what the actual test (ICMP ping, UDP Echoplus) that wa= s to be run for the action. BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Monday, August 22, 2016 8:05 AM To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] well known channel names One point that has come up in IPPM discussion: The Fixed and Run Tine Parameters in the registry all have names, but we ma= y need to form a sub-registry to ensure that the names are used consistentl= y (among different registry entries, and in their interpretation by other o= perations, e.g., as options in LMAP). IPPM agreed to continue with the IANA early review, and determine the effic= acy of the parameter sub-registry in those conversations (on-going). Otherwise, I would like to hear what else is necessary (The IPPM RFCs and M= etric entries are not abstract, IMO). regards, Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Sunday, August 21, 2016 8:58 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > Subject: RE: [lmap] well known channel names >=20 > Juergen, >=20 > Indeed in the BBF we are thinking about the same thing (having own own > registry) for non-measurement related tasks and diagnostic tasks that=20 > are not strictly associated with a metric (e.g., HTTP Upload). > These should be new charter items IMHO. >=20 > I did think though IPPM would define the metrics sufficient enough=20 > that they would be self describing in that that they can be used=20 > directly as LMAP actions (including the actual test ala ICMP Ping) to run= . >=20 > Looking at ietf-ippm-initial-registry (at least the first one in=20 > section > 4) why do you think this is insufficient? >=20 > I would like to hear Al's thoughts if he believes another registry is=20 > necessary for implementing IPPM entries as testable tasks. >=20 > BR, > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > university.de] > Sent: Monday, August 15, 2016 7:54 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] well known channel names >=20 > Tim, >=20 > I arrived at this conclusion because of two observations: >=20 > (a) LMAP has tasks that are not measurement tasks (like a reporting > task) that will benefit of having some knowledge about common > options; the metric registry does not apply to these > non-measurement tasks (unless we start introducing pseudo > metrics). >=20 > (b) We have been struggling with the question to what extend the IPPM > metric registry is expected to drive automation (e.g, does the > IPPM registry define LMAP option names and how parameters are > encoded as LMAP option values). >=20 > If there would be an LMAP task registry, then the IPPM registry could=20 > focus on the abstract definition of metrics while the LMAP task=20 > registry would provide the binding to LMAP tasks, that is, how=20 > concrete tasks name use options etc to control the parameters defined in = IPPM metrics. > The LMAP task metric would likely be read by tools while the IPPM=20 > metric would likely be read by code developers. For me, this started=20 > to look like a rather natural split of concerns. >=20 > /js >=20 > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) > wrote: > > Juergen, > > > > The text seems fine to me. > > > > As to the LMAP registry, I know in the BBF we also plan to have a > registry as well for some of the BBF specific tests and metrics.=20 > However we didn't think we should "wrapper" or "reference" the IPPM=20 > registry entries as they were suppose to be used directly in LMAP. I'm=20 > not sure why you would think that would be needed? > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, August 12, 2016 6:09 AM > > To: lmap@ietf.org > > Subject: [lmap] well known channel names > > > > Hi, > > > > here is an attempt to resolve the discussion around option names. > > > > OLD > > > > While many of the Task Configuration Options are left to individual > > tasks to define, some common Options are used by multiple tasks and > > benefit from standardisation: > > > > o Channel is used to specify the details of an endpoint for > Control > > or Reporting Task communications and is detailed elsewhere in > this > > document. The common option name for specifying the channel is > > "channel". > > > > NEW > > > > The ma-option-obj is used to define Task Configuration Options. > Task > > Configuration Options are generally task specific. For tasks > > associated with an entry in a registry, the registry may define > well- > > known option names (e.g., the so-called parameters in the IPPM > metric > > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > > Tasks need to know the Channel they are going to use. The common > > option name for specifying the channel is "channel" where the > > option's value refers to the name of an ma-channel-obj. > > > > My intention was to explain more clearly that some of the option=20 > > names > fall out of registries (e.g., the IPPM metric registry). I kept the=20 > definition of the well-known "channel" option name and I clarified=20 > that the value of this well-known option refers to the name of an=20 > ma-channel- obj. > > > > Personally, I would have preferred if we would not hard code any > option names in the information model. I would rather have a simple=20 > LMAP task registry for (non-measurement) tasks that defines task=20 > specific parameters or options. This would give us the flexibility to=20 > define common non-measurement task options when we need them. But for=20 > the sake of wrapping this document up in a timely manner, I am willing=20 > to go along with the proposed text. > > > > That all said, I personally find the IPPM metry registry somewhat=20 > > difficult to work with. I could envision an approach where we=20 > > complement the IPPM metric registry with an LMAP task registry that=20 > > simply defines LMAP tasks, their functionality, and their well-known=20 > > options. For measurement tasks, this LMAP task registry would refer=20 > > to the IPPM metric registry which has all the details for the=20 > > differnet IPPM metrics. For non-measurement tasks, the LMAP task=20 > > registry would provide the information necessary to use them in an=20 > > interoperable manner, such as the channel name or the flag whether=20 > > empty reports should be suppressed for report tasks. In essence,=20 > > such an LMAP task registry would consist of > > > > - a URI > > - a short description > > - an optional reference to a metric registry > > - a list of well-known option names, each with a short description > > > > and this would give us a well-known URI for identifying lets say an > LMAP reporting task that has well-known options and we would not need=20 > to hard-code anything in the information model. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > >=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 Mon Aug 22 08:13:51 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CF12D64F for ; Mon, 22 Aug 2016 08:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 zlypNpdN11Wh for ; Mon, 22 Aug 2016 08:13:48 -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 4862912B059 for ; Mon, 22 Aug 2016 08:13:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A029B740; Mon, 22 Aug 2016 17:13:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3O7WQLEVX6TA; Mon, 22 Aug 2016 17:13:42 +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, 22 Aug 2016 17:13:45 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73B43200AD; Mon, 22 Aug 2016 17:13:45 +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 UashPW5-Mxbr; Mon, 22 Aug 2016 17:13:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6974F200AB; Mon, 22 Aug 2016 17:13:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EF8D23C2C0E0; Mon, 22 Aug 2016 17:13:42 +0200 (CEST) Date: Mon, 22 Aug 2016 17:13:40 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160822151337.GB13364@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77012A729EEE@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160822073340.GB11509@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A807@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72A807@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Information Draft 11 - minor edits X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 15:13:50 -0000 Tim, now I see, the list labels are wrong. Will be fixed in -12. /js On Mon, Aug 22, 2016 at 11:49:58AM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Section 3.5.6 - in the description refers to the ma-status-schedule-name not ma-status-suppression-name; same for state attribute. > > 3.5.6. Definition of ma-status-suppression-obj > object { > string ma-status-suppression-name; > string ma-status-suppression-state; > } ma-status-suppression-obj; > The ma-status-suppression-obj provides status information about that > status of a suppression and consists of the following elements: > ma-status-schedule-name: The name of the suppression this status > object refers to. > ma-status-schedule-state: The state of the suppression. The value > 'enabled' indicates that the suppression > is currently enabled. The value 'active > indicates that the suppression is > currently active. The value 'disabled' > indicates that the suppression is > currently disabled. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, August 22, 2016 2:34 AM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] Information Draft 11 - minor edits > > On Sat, Aug 20, 2016 at 05:17:48PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > > > I was going through Information Model draft 11 and found the following items (nothing big): > > > > 1) Typo (triggerent) > > > > ma-report-result-event-time: The date and time of the event that > > > > > > triggerent the schedule of the action > > > > > > that produced the reported result > > > > > > values. The date and time does not > > > > > > include any added randomization. > > Fixed. > > > 2) ma-status-suppression-obj > > The elements refer to > > ma-status-schedule-... not ma-status-supression-... > > I do not understand / find the issue. Can you please elaborate? > > /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 Mon Aug 22 08:40:14 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E93127735 for ; Mon, 22 Aug 2016 08:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 5pOyzKW111t0 for ; Mon, 22 Aug 2016 08:40:11 -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 2D7D812B075 for ; Mon, 22 Aug 2016 08:40:11 -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 D95F1120E0B; Mon, 22 Aug 2016 11:53:07 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 97D61E331A; Mon, 22 Aug 2016 11:37:58 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 22 Aug 2016 11:40:10 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Date: Mon, 22 Aug 2016 11:40:09 -0400 Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEA== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 15:40:13 -0000 Hi Tim, Maybe we can improve the Description, to mention UDP or other deatils? https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#section-4.1= .4 Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, August 22, 2016 10:47 AM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Al, >=20 > I will say that when I looked at the first registry entry is was > difficult for me to understand what the actual test (ICMP ping, UDP > Echoplus) that was to be run for the action. >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 8:05 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > One point that has come up in IPPM discussion: >=20 > The Fixed and Run Tine Parameters in the registry all have names, but we > may need to form a sub-registry to ensure that the names are used > consistently (among different registry entries, and in their > interpretation by other operations, e.g., as options in LMAP). >=20 > IPPM agreed to continue with the IANA early review, and determine the > efficacy of the parameter sub-registry in those conversations (on- > going). >=20 > Otherwise, I would like to hear what else is necessary (The IPPM RFCs > and Metric entries are not abstract, IMO). >=20 > regards, > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Sunday, August 21, 2016 8:58 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > Subject: RE: [lmap] well known channel names > > > > Juergen, > > > > Indeed in the BBF we are thinking about the same thing (having own own > > registry) for non-measurement related tasks and diagnostic tasks that > > are not strictly associated with a metric (e.g., HTTP Upload). > > These should be new charter items IMHO. > > > > I did think though IPPM would define the metrics sufficient enough > > that they would be self describing in that that they can be used > > directly as LMAP actions (including the actual test ala ICMP Ping) to > run. > > > > Looking at ietf-ippm-initial-registry (at least the first one in > > section > > 4) why do you think this is insufficient? > > > > I would like to hear Al's thoughts if he believes another registry is > > necessary for implementing IPPM entries as testable tasks. > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Monday, August 15, 2016 7:54 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] well known channel names > > > > Tim, > > > > I arrived at this conclusion because of two observations: > > > > (a) LMAP has tasks that are not measurement tasks (like a reporting > > task) that will benefit of having some knowledge about common > > options; the metric registry does not apply to these > > non-measurement tasks (unless we start introducing pseudo > > metrics). > > > > (b) We have been struggling with the question to what extend the IPPM > > metric registry is expected to drive automation (e.g, does the > > IPPM registry define LMAP option names and how parameters are > > encoded as LMAP option values). > > > > If there would be an LMAP task registry, then the IPPM registry could > > focus on the abstract definition of metrics while the LMAP task > > registry would provide the binding to LMAP tasks, that is, how > > concrete tasks name use options etc to control the parameters defined > in IPPM metrics. > > The LMAP task metric would likely be read by tools while the IPPM > > metric would likely be read by code developers. For me, this started > > to look like a rather natural split of concerns. > > > > /js > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - US) > > wrote: > > > Juergen, > > > > > > The text seems fine to me. > > > > > > As to the LMAP registry, I know in the BBF we also plan to have a > > registry as well for some of the BBF specific tests and metrics. > > However we didn't think we should "wrapper" or "reference" the IPPM > > registry entries as they were suppose to be used directly in LMAP. I'm > > not sure why you would think that would be needed? > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Friday, August 12, 2016 6:09 AM > > > To: lmap@ietf.org > > > Subject: [lmap] well known channel names > > > > > > Hi, > > > > > > here is an attempt to resolve the discussion around option names. > > > > > > OLD > > > > > > While many of the Task Configuration Options are left to > individual > > > tasks to define, some common Options are used by multiple tasks > and > > > benefit from standardisation: > > > > > > o Channel is used to specify the details of an endpoint for > > Control > > > or Reporting Task communications and is detailed elsewhere in > > this > > > document. The common option name for specifying the channel > is > > > "channel". > > > > > > NEW > > > > > > The ma-option-obj is used to define Task Configuration Options. > > Task > > > Configuration Options are generally task specific. For tasks > > > associated with an entry in a registry, the registry may define > > well- > > > known option names (e.g., the so-called parameters in the IPPM > > metric > > > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > > > Tasks need to know the Channel they are going to use. The common > > > option name for specifying the channel is "channel" where the > > > option's value refers to the name of an ma-channel-obj. > > > > > > My intention was to explain more clearly that some of the option > > > names > > fall out of registries (e.g., the IPPM metric registry). I kept the > > definition of the well-known "channel" option name and I clarified > > that the value of this well-known option refers to the name of an > > ma-channel- obj. > > > > > > Personally, I would have preferred if we would not hard code any > > option names in the information model. I would rather have a simple > > LMAP task registry for (non-measurement) tasks that defines task > > specific parameters or options. This would give us the flexibility to > > define common non-measurement task options when we need them. But for > > the sake of wrapping this document up in a timely manner, I am willing > > to go along with the proposed text. > > > > > > That all said, I personally find the IPPM metry registry somewhat > > > difficult to work with. I could envision an approach where we > > > complement the IPPM metric registry with an LMAP task registry that > > > simply defines LMAP tasks, their functionality, and their well-known > > > options. For measurement tasks, this LMAP task registry would refer > > > to the IPPM metric registry which has all the details for the > > > differnet IPPM metrics. For non-measurement tasks, the LMAP task > > > registry would provide the information necessary to use them in an > > > interoperable manner, such as the channel name or the flag whether > > > empty reports should be suppressed for report tasks. In essence, > > > such an LMAP task registry would consist of > > > > > > - a URI > > > - a short description > > > - an optional reference to a metric registry > > > - a list of well-known option names, each with a short description > > > > > > and this would give us a well-known URI for identifying lets say an > > LMAP reporting task that has well-known options and we would not need > > to hard-code anything in the information model. > > > > > > /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 Mon Aug 22 08:46:50 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44412D550 for ; Mon, 22 Aug 2016 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yKZIsUMlctDk for ; Mon, 22 Aug 2016 08:46:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856DE12B075 for ; Mon, 22 Aug 2016 08:46:46 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 181AEDDA31322; Mon, 22 Aug 2016 15:46:43 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u7MFkjD0027537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 15:46:45 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u7MFkiIn027228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 15:46:44 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 22 Aug 2016 11:46:44 -0400 From: "Carey, Timothy (Nokia - US)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3g Date: Mon, 22 Aug 2016 15:46:43 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 15:46:48 -0000 Al, I thought it would be in the method of measurement section. RFC 2681 doesn't explicitly call out the test that I could easily find alth= ough it does say you can use ping. If we are explicit in the test actual test to run for the metric in the met= hod (or description) - I can then run that test with the inputs and outputs= for the assigned role. BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Monday, August 22, 2016 10:40 AM To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] well known channel names Hi Tim, Maybe we can improve the Description, to mention UDP or other deatils? https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#section-4.1= .4 Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, August 22, 2016 10:47 AM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Al, >=20 > I will say that when I looked at the first registry entry is was=20 > difficult for me to understand what the actual test (ICMP ping, UDP > Echoplus) that was to be run for the action. >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 8:05 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > One point that has come up in IPPM discussion: >=20 > The Fixed and Run Tine Parameters in the registry all have names, but=20 > we may need to form a sub-registry to ensure that the names are used=20 > consistently (among different registry entries, and in their=20 > interpretation by other operations, e.g., as options in LMAP). >=20 > IPPM agreed to continue with the IANA early review, and determine the=20 > efficacy of the parameter sub-registry in those conversations (on-=20 > going). >=20 > Otherwise, I would like to hear what else is necessary (The IPPM RFCs=20 > and Metric entries are not abstract, IMO). >=20 > regards, > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Sunday, August 21, 2016 8:58 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > Subject: RE: [lmap] well known channel names > > > > Juergen, > > > > Indeed in the BBF we are thinking about the same thing (having own=20 > > own > > registry) for non-measurement related tasks and diagnostic tasks=20 > > that are not strictly associated with a metric (e.g., HTTP Upload). > > These should be new charter items IMHO. > > > > I did think though IPPM would define the metrics sufficient enough=20 > > that they would be self describing in that that they can be used=20 > > directly as LMAP actions (including the actual test ala ICMP Ping)=20 > > to > run. > > > > Looking at ietf-ippm-initial-registry (at least the first one in=20 > > section > > 4) why do you think this is insufficient? > > > > I would like to hear Al's thoughts if he believes another registry=20 > > is necessary for implementing IPPM entries as testable tasks. > > > > BR, > > Tim > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > university.de] > > Sent: Monday, August 15, 2016 7:54 AM > > To: Carey, Timothy (Nokia - US) > > Cc: lmap@ietf.org > > Subject: Re: [lmap] well known channel names > > > > Tim, > > > > I arrived at this conclusion because of two observations: > > > > (a) LMAP has tasks that are not measurement tasks (like a reporting > > task) that will benefit of having some knowledge about common > > options; the metric registry does not apply to these > > non-measurement tasks (unless we start introducing pseudo > > metrics). > > > > (b) We have been struggling with the question to what extend the IPPM > > metric registry is expected to drive automation (e.g, does the > > IPPM registry define LMAP option names and how parameters are > > encoded as LMAP option values). > > > > If there would be an LMAP task registry, then the IPPM registry=20 > > could focus on the abstract definition of metrics while the LMAP=20 > > task registry would provide the binding to LMAP tasks, that is, how=20 > > concrete tasks name use options etc to control the parameters=20 > > defined > in IPPM metrics. > > The LMAP task metric would likely be read by tools while the IPPM=20 > > metric would likely be read by code developers. For me, this started=20 > > to look like a rather natural split of concerns. > > > > /js > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia -=20 > > US) > > wrote: > > > Juergen, > > > > > > The text seems fine to me. > > > > > > As to the LMAP registry, I know in the BBF we also plan to have a > > registry as well for some of the BBF specific tests and metrics. > > However we didn't think we should "wrapper" or "reference" the IPPM=20 > > registry entries as they were suppose to be used directly in LMAP.=20 > > I'm not sure why you would think that would be needed? > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Friday, August 12, 2016 6:09 AM > > > To: lmap@ietf.org > > > Subject: [lmap] well known channel names > > > > > > Hi, > > > > > > here is an attempt to resolve the discussion around option names. > > > > > > OLD > > > > > > While many of the Task Configuration Options are left to > individual > > > tasks to define, some common Options are used by multiple tasks > and > > > benefit from standardisation: > > > > > > o Channel is used to specify the details of an endpoint for > > Control > > > or Reporting Task communications and is detailed elsewhere=20 > > > in > > this > > > document. The common option name for specifying the channel > is > > > "channel". > > > > > > NEW > > > > > > The ma-option-obj is used to define Task Configuration Options. > > Task > > > Configuration Options are generally task specific. For tasks > > > associated with an entry in a registry, the registry may define > > well- > > > known option names (e.g., the so-called parameters in the IPPM > > metric > > > registry [I-D.ietf-ippm-metric-registry]). Control and Reporting > > > Tasks need to know the Channel they are going to use. The common > > > option name for specifying the channel is "channel" where the > > > option's value refers to the name of an ma-channel-obj. > > > > > > My intention was to explain more clearly that some of the option=20 > > > names > > fall out of registries (e.g., the IPPM metric registry). I kept the=20 > > definition of the well-known "channel" option name and I clarified=20 > > that the value of this well-known option refers to the name of an > > ma-channel- obj. > > > > > > Personally, I would have preferred if we would not hard code any > > option names in the information model. I would rather have a simple=20 > > LMAP task registry for (non-measurement) tasks that defines task=20 > > specific parameters or options. This would give us the flexibility=20 > > to define common non-measurement task options when we need them. But=20 > > for the sake of wrapping this document up in a timely manner, I am=20 > > willing to go along with the proposed text. > > > > > > That all said, I personally find the IPPM metry registry somewhat=20 > > > difficult to work with. I could envision an approach where we=20 > > > complement the IPPM metric registry with an LMAP task registry=20 > > > that simply defines LMAP tasks, their functionality, and their=20 > > > well-known options. For measurement tasks, this LMAP task registry=20 > > > would refer to the IPPM metric registry which has all the details=20 > > > for the differnet IPPM metrics. For non-measurement tasks, the=20 > > > LMAP task registry would provide the information necessary to use=20 > > > them in an interoperable manner, such as the channel name or the=20 > > > flag whether empty reports should be suppressed for report tasks.=20 > > > In essence, such an LMAP task registry would consist of > > > > > > - a URI > > > - a short description > > > - an optional reference to a metric registry > > > - a list of well-known option names, each with a short=20 > > > description > > > > > > and this would give us a well-known URI for identifying lets say=20 > > > an > > LMAP reporting task that has well-known options and we would not=20 > > need to hard-code anything in the information model. > > > > > > /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 Mon Aug 22 08:57:58 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4812D10F for ; Mon, 22 Aug 2016 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 UdLMh17PlM7B for ; Mon, 22 Aug 2016 08:57:55 -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 D1BA212D5AE for ; Mon, 22 Aug 2016 08:57:54 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id A100A121093; Mon, 22 Aug 2016 12:10:51 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-azure.research.att.com (Postfix) with ESMTP id 87165E11F7; Mon, 22 Aug 2016 11:57:54 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 22 Aug 2016 11:57:54 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Date: Mon, 22 Aug 2016 11:57:52 -0400 Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3ggAABLhA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 15:57:57 -0000 Hi Tim, When you say "actual test to run", are you referring to the=20 software tool that would perform one role of the test? When RFC2681 mentions ping, it also reminds the reader=20 that the RT delay would be based on ICMP echo request/reply. This is not the same measurement as the UDP RT Delay would measure, possibly for the reasons cited in section 2.6: {Comment: "ping" would qualify as a round-trip measure under this definition, with a Type-P of ICMP echo request/reply with 60-byte packets. However, the uncertainties associated with a typical ping program must be analyzed as in the next section, including the type of reflecting point (a router may not handle an ICMP request in the fast path) and effects of load on the reflecting point.} Is "test" synonymous with SW tool below? Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, August 22, 2016 11:47 AM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Al, >=20 > I thought it would be in the method of measurement section. > RFC 2681 doesn't explicitly call out the test that I could easily find > although it does say you can use ping. >=20 > If we are explicit in the test actual test to run for the metric in the > method (or description) - I can then run that test with the inputs and > outputs for the assigned role. >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 10:40 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Hi Tim, > Maybe we can improve the Description, to mention UDP or other deatils? > https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#section- > 4.1.4 >=20 > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Monday, August 22, 2016 10:47 AM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Al, > > > > I will say that when I looked at the first registry entry is was > > difficult for me to understand what the actual test (ICMP ping, UDP > > Echoplus) that was to be run for the action. > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Monday, August 22, 2016 8:05 AM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > One point that has come up in IPPM discussion: > > > > The Fixed and Run Tine Parameters in the registry all have names, but > > we may need to form a sub-registry to ensure that the names are used > > consistently (among different registry entries, and in their > > interpretation by other operations, e.g., as options in LMAP). > > > > IPPM agreed to continue with the IANA early review, and determine the > > efficacy of the parameter sub-registry in those conversations (on- > > going). > > > > Otherwise, I would like to hear what else is necessary (The IPPM RFCs > > and Metric entries are not abstract, IMO). > > > > regards, > > Al > > > > > -----Original Message----- > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Sunday, August 21, 2016 8:58 PM > > > To: Juergen Schoenwaelder > > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > > Subject: RE: [lmap] well known channel names > > > > > > Juergen, > > > > > > Indeed in the BBF we are thinking about the same thing (having own > > > own > > > registry) for non-measurement related tasks and diagnostic tasks > > > that are not strictly associated with a metric (e.g., HTTP Upload). > > > These should be new charter items IMHO. > > > > > > I did think though IPPM would define the metrics sufficient enough > > > that they would be self describing in that that they can be used > > > directly as LMAP actions (including the actual test ala ICMP Ping) > > > to > > run. > > > > > > Looking at ietf-ippm-initial-registry (at least the first one in > > > section > > > 4) why do you think this is insufficient? > > > > > > I would like to hear Al's thoughts if he believes another registry > > > is necessary for implementing IPPM entries as testable tasks. > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Monday, August 15, 2016 7:54 AM > > > To: Carey, Timothy (Nokia - US) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] well known channel names > > > > > > Tim, > > > > > > I arrived at this conclusion because of two observations: > > > > > > (a) LMAP has tasks that are not measurement tasks (like a reporting > > > task) that will benefit of having some knowledge about common > > > options; the metric registry does not apply to these > > > non-measurement tasks (unless we start introducing pseudo > > > metrics). > > > > > > (b) We have been struggling with the question to what extend the > IPPM > > > metric registry is expected to drive automation (e.g, does the > > > IPPM registry define LMAP option names and how parameters are > > > encoded as LMAP option values). > > > > > > If there would be an LMAP task registry, then the IPPM registry > > > could focus on the abstract definition of metrics while the LMAP > > > task registry would provide the binding to LMAP tasks, that is, how > > > concrete tasks name use options etc to control the parameters > > > defined > > in IPPM metrics. > > > The LMAP task metric would likely be read by tools while the IPPM > > > metric would likely be read by code developers. For me, this started > > > to look like a rather natural split of concerns. > > > > > > /js > > > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - > > > US) > > > wrote: > > > > Juergen, > > > > > > > > The text seems fine to me. > > > > > > > > As to the LMAP registry, I know in the BBF we also plan to have a > > > registry as well for some of the BBF specific tests and metrics. > > > However we didn't think we should "wrapper" or "reference" the IPPM > > > registry entries as they were suppose to be used directly in LMAP. > > > I'm not sure why you would think that would be needed? > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Friday, August 12, 2016 6:09 AM > > > > To: lmap@ietf.org > > > > Subject: [lmap] well known channel names > > > > > > > > Hi, > > > > > > > > here is an attempt to resolve the discussion around option names. > > > > > > > > OLD > > > > > > > > While many of the Task Configuration Options are left to > > individual > > > > tasks to define, some common Options are used by multiple tasks > > and > > > > benefit from standardisation: > > > > > > > > o Channel is used to specify the details of an endpoint for > > > Control > > > > or Reporting Task communications and is detailed elsewhere > > > > in > > > this > > > > document. The common option name for specifying the channel > > is > > > > "channel". > > > > > > > > NEW > > > > > > > > The ma-option-obj is used to define Task Configuration Options. > > > Task > > > > Configuration Options are generally task specific. For tasks > > > > associated with an entry in a registry, the registry may define > > > well- > > > > known option names (e.g., the so-called parameters in the IPPM > > > metric > > > > registry [I-D.ietf-ippm-metric-registry]). Control and > Reporting > > > > Tasks need to know the Channel they are going to use. The > common > > > > option name for specifying the channel is "channel" where the > > > > option's value refers to the name of an ma-channel-obj. > > > > > > > > My intention was to explain more clearly that some of the option > > > > names > > > fall out of registries (e.g., the IPPM metric registry). I kept the > > > definition of the well-known "channel" option name and I clarified > > > that the value of this well-known option refers to the name of an > > > ma-channel- obj. > > > > > > > > Personally, I would have preferred if we would not hard code any > > > option names in the information model. I would rather have a simple > > > LMAP task registry for (non-measurement) tasks that defines task > > > specific parameters or options. This would give us the flexibility > > > to define common non-measurement task options when we need them. But > > > for the sake of wrapping this document up in a timely manner, I am > > > willing to go along with the proposed text. > > > > > > > > That all said, I personally find the IPPM metry registry somewhat > > > > difficult to work with. I could envision an approach where we > > > > complement the IPPM metric registry with an LMAP task registry > > > > that simply defines LMAP tasks, their functionality, and their > > > > well-known options. For measurement tasks, this LMAP task registry > > > > would refer to the IPPM metric registry which has all the details > > > > for the differnet IPPM metrics. For non-measurement tasks, the > > > > LMAP task registry would provide the information necessary to use > > > > them in an interoperable manner, such as the channel name or the > > > > flag whether empty reports should be suppressed for report tasks. > > > > In essence, such an LMAP task registry would consist of > > > > > > > > - a URI > > > > - a short description > > > > - an optional reference to a metric registry > > > > - a list of well-known option names, each with a short > > > > description > > > > > > > > and this would give us a well-known URI for identifying lets say > > > > an > > > LMAP reporting task that has well-known options and we would not > > > need to hard-code anything in the information model. > > > > > > > > /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 Mon Aug 22 09:45:37 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0EC12D177 for ; Mon, 22 Aug 2016 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 auKKmWrSHdDi for ; Mon, 22 Aug 2016 09:45:32 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2F512D0A0 for ; Mon, 22 Aug 2016 09:45:32 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 26D5D7F75323C; Mon, 22 Aug 2016 16:45:29 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u7MGjVSM013589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 16:45:31 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u7MGjV80009470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 16:45:31 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 22 Aug 2016 12:45:31 -0400 From: "Carey, Timothy (Nokia - US)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3ggAABLhCAAAsKcA== Date: Mon, 22 Aug 2016 16:45:30 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 16:45:36 -0000 Al, I didn't anything referencing "SW tool" in this thread. Is ICMP ping a SW tool in your mind? That is what I was referring to as a t= est. I certainly am not referring to LMAP as the test or SW tool in this t= hread. For example in section 7 of the initial registry draft - infers TWAMP is th= e test used (yes I know it's a protocol).=20 I guess I should have said the protocol to use for the actual measurement..= .. For section 5 PDV what is the protocol to use for the actual measurement= ?=20 BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Monday, August 22, 2016 10:58 AM To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] well known channel names Hi Tim, When you say "actual test to run", are you referring to the software tool t= hat would perform one role of the test? When RFC2681 mentions ping, it also reminds the reader that the RT delay wo= uld be based on ICMP echo request/reply. This is not the same measurement as the UDP RT Delay would measure, possibl= y for the reasons cited in section 2.6: {Comment: "ping" would qualify as a round-trip measure under this definition, with a Type-P of ICMP echo request/reply with 60-byte packets. However, the uncertainties associated with a typical ping program must be analyzed as in the next section, including the type of reflecting point (a router may not handle an ICMP request in the fast path) and effects of load on the reflecting point.} Is "test" synonymous with SW tool below? Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, August 22, 2016 11:47 AM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Al, >=20 > I thought it would be in the method of measurement section. > RFC 2681 doesn't explicitly call out the test that I could easily find=20 > although it does say you can use ping. >=20 > If we are explicit in the test actual test to run for the metric in=20 > the method (or description) - I can then run that test with the inputs=20 > and outputs for the assigned role. >=20 > BR, > Tim >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 10:40 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Hi Tim, > Maybe we can improve the Description, to mention UDP or other deatils? > https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#sectio > n- > 4.1.4 >=20 > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Monday, August 22, 2016 10:47 AM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Al, > > > > I will say that when I looked at the first registry entry is was=20 > > difficult for me to understand what the actual test (ICMP ping, UDP > > Echoplus) that was to be run for the action. > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Monday, August 22, 2016 8:05 AM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > One point that has come up in IPPM discussion: > > > > The Fixed and Run Tine Parameters in the registry all have names,=20 > > but we may need to form a sub-registry to ensure that the names are=20 > > used consistently (among different registry entries, and in their=20 > > interpretation by other operations, e.g., as options in LMAP). > > > > IPPM agreed to continue with the IANA early review, and determine=20 > > the efficacy of the parameter sub-registry in those conversations=20 > > (on- going). > > > > Otherwise, I would like to hear what else is necessary (The IPPM=20 > > RFCs and Metric entries are not abstract, IMO). > > > > regards, > > Al > > > > > -----Original Message----- > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Sunday, August 21, 2016 8:58 PM > > > To: Juergen Schoenwaelder > > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > > Subject: RE: [lmap] well known channel names > > > > > > Juergen, > > > > > > Indeed in the BBF we are thinking about the same thing (having own=20 > > > own > > > registry) for non-measurement related tasks and diagnostic tasks=20 > > > that are not strictly associated with a metric (e.g., HTTP Upload). > > > These should be new charter items IMHO. > > > > > > I did think though IPPM would define the metrics sufficient enough=20 > > > that they would be self describing in that that they can be used=20 > > > directly as LMAP actions (including the actual test ala ICMP Ping)=20 > > > to > > run. > > > > > > Looking at ietf-ippm-initial-registry (at least the first one in=20 > > > section > > > 4) why do you think this is insufficient? > > > > > > I would like to hear Al's thoughts if he believes another registry=20 > > > is necessary for implementing IPPM entries as testable tasks. > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > > university.de] > > > Sent: Monday, August 15, 2016 7:54 AM > > > To: Carey, Timothy (Nokia - US) > > > Cc: lmap@ietf.org > > > Subject: Re: [lmap] well known channel names > > > > > > Tim, > > > > > > I arrived at this conclusion because of two observations: > > > > > > (a) LMAP has tasks that are not measurement tasks (like a reporting > > > task) that will benefit of having some knowledge about common > > > options; the metric registry does not apply to these > > > non-measurement tasks (unless we start introducing pseudo > > > metrics). > > > > > > (b) We have been struggling with the question to what extend the > IPPM > > > metric registry is expected to drive automation (e.g, does the > > > IPPM registry define LMAP option names and how parameters are > > > encoded as LMAP option values). > > > > > > If there would be an LMAP task registry, then the IPPM registry=20 > > > could focus on the abstract definition of metrics while the LMAP=20 > > > task registry would provide the binding to LMAP tasks, that is,=20 > > > how concrete tasks name use options etc to control the parameters=20 > > > defined > > in IPPM metrics. > > > The LMAP task metric would likely be read by tools while the IPPM=20 > > > metric would likely be read by code developers. For me, this=20 > > > started to look like a rather natural split of concerns. > > > > > > /js > > > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - > > > US) > > > wrote: > > > > Juergen, > > > > > > > > The text seems fine to me. > > > > > > > > As to the LMAP registry, I know in the BBF we also plan to have=20 > > > > a > > > registry as well for some of the BBF specific tests and metrics. > > > However we didn't think we should "wrapper" or "reference" the=20 > > > IPPM registry entries as they were suppose to be used directly in LMA= P. > > > I'm not sure why you would think that would be needed? > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > Sent: Friday, August 12, 2016 6:09 AM > > > > To: lmap@ietf.org > > > > Subject: [lmap] well known channel names > > > > > > > > Hi, > > > > > > > > here is an attempt to resolve the discussion around option names. > > > > > > > > OLD > > > > > > > > While many of the Task Configuration Options are left to > > individual > > > > tasks to define, some common Options are used by multiple=20 > > > > tasks > > and > > > > benefit from standardisation: > > > > > > > > o Channel is used to specify the details of an endpoint for > > > Control > > > > or Reporting Task communications and is detailed elsewhere=20 > > > > in > > > this > > > > document. The common option name for specifying the=20 > > > > channel > > is > > > > "channel". > > > > > > > > NEW > > > > > > > > The ma-option-obj is used to define Task Configuration Options. > > > Task > > > > Configuration Options are generally task specific. For tasks > > > > associated with an entry in a registry, the registry may=20 > > > > define > > > well- > > > > known option names (e.g., the so-called parameters in the=20 > > > > IPPM > > > metric > > > > registry [I-D.ietf-ippm-metric-registry]). Control and > Reporting > > > > Tasks need to know the Channel they are going to use. The > common > > > > option name for specifying the channel is "channel" where the > > > > option's value refers to the name of an ma-channel-obj. > > > > > > > > My intention was to explain more clearly that some of the option=20 > > > > names > > > fall out of registries (e.g., the IPPM metric registry). I kept=20 > > > the definition of the well-known "channel" option name and I=20 > > > clarified that the value of this well-known option refers to the=20 > > > name of an > > > ma-channel- obj. > > > > > > > > Personally, I would have preferred if we would not hard code any > > > option names in the information model. I would rather have a=20 > > > simple LMAP task registry for (non-measurement) tasks that defines=20 > > > task specific parameters or options. This would give us the=20 > > > flexibility to define common non-measurement task options when we=20 > > > need them. But for the sake of wrapping this document up in a=20 > > > timely manner, I am willing to go along with the proposed text. > > > > > > > > That all said, I personally find the IPPM metry registry=20 > > > > somewhat difficult to work with. I could envision an approach=20 > > > > where we complement the IPPM metric registry with an LMAP task=20 > > > > registry that simply defines LMAP tasks, their functionality,=20 > > > > and their well-known options. For measurement tasks, this LMAP=20 > > > > task registry would refer to the IPPM metric registry which has=20 > > > > all the details for the differnet IPPM metrics. For=20 > > > > non-measurement tasks, the LMAP task registry would provide the=20 > > > > information necessary to use them in an interoperable manner,=20 > > > > such as the channel name or the flag whether empty reports should b= e suppressed for report tasks. > > > > In essence, such an LMAP task registry would consist of > > > > > > > > - a URI > > > > - a short description > > > > - an optional reference to a metric registry > > > > - a list of well-known option names, each with a short=20 > > > > description > > > > > > > > and this would give us a well-known URI for identifying lets say=20 > > > > an > > > LMAP reporting task that has well-known options and we would not=20 > > > need to hard-code anything in the information model. > > > > > > > > /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 Mon Aug 22 11:42:34 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1814812D097 for ; Mon, 22 Aug 2016 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 AJbKgsEjmx68 for ; Mon, 22 Aug 2016 11:42:30 -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 CB66112B02F for ; Mon, 22 Aug 2016 11:42: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 DA931120D0C; Mon, 22 Aug 2016 14:55:26 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 68EB1F050E; Mon, 22 Aug 2016 14:42:26 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 22 Aug 2016 14:42:26 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Date: Mon, 22 Aug 2016 14:42:24 -0400 Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3ggAABLhCAAAsKcIAAIPTw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B62536@NJFPSRVEXG0.research.att.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 18:42:32 -0000 Hi Tim, Although ping is synonymous with sending ICMP echo requests, ping is a SW tool for controlling send/receive/results reporting. That's not just in my mind, it's in the *nix man pages: http://www.unix.com/man-page/linux/8/ping/=20 Let me try this as the explanation: The type of packets used in the measurement are specified in=20 the metric registry, so you will see IP/UDP in the entries now. We have a request to specify an IP/ICMP round trip time metric, TBD. But the metric registry is currently agnostic to the measurement=20 control protocol for arranging measurements between MAs or MA - MP (the IPPM RFCs for metrics are agnostic too: they existed before OWAMP and TWAMP). So, specifying that the measurement is conducted using TWAMP, IPSLA, netperf, some tool that launches DNS requests, or ping=20 is a configuration option/parameter that currently needs to be communicated in addition to the registry entry. hope this helps, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > (Nokia - US) > Sent: Monday, August 22, 2016 12:46 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] well known channel names >=20 > Al, >=20 > I didn't anything referencing "SW tool" in this thread. >=20 > Is ICMP ping a SW tool in your mind? That is what I was referring to as > a test. I certainly am not referring to LMAP as the test or SW tool in > this thread. >=20 > For example in section 7 of the initial registry draft - infers TWAMP is > the test used (yes I know it's a protocol). >=20 > I guess I should have said the protocol to use for the actual > measurement.... For section 5 PDV what is the protocol to use for the > actual measurement? >=20 > BR, > Tim >=20 >=20 >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 10:58 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Hi Tim, > When you say "actual test to run", are you referring to the software > tool that would perform one role of the test? >=20 > When RFC2681 mentions ping, it also reminds the reader that the RT delay > would be based on ICMP echo request/reply. > This is not the same measurement as the UDP RT Delay would measure, > possibly for the reasons cited in section 2.6: >=20 > {Comment: "ping" would qualify as a round-trip measure under this > definition, with a Type-P of ICMP echo request/reply with 60-byte > packets. However, the uncertainties associated with a typical ping > program must be analyzed as in the next section, including the type > of reflecting point (a router may not handle an ICMP request in the > fast path) and effects of load on the reflecting point.} >=20 > Is "test" synonymous with SW tool below? > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Monday, August 22, 2016 11:47 AM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Al, > > > > I thought it would be in the method of measurement section. > > RFC 2681 doesn't explicitly call out the test that I could easily find > > although it does say you can use ping. > > > > If we are explicit in the test actual test to run for the metric in > > the method (or description) - I can then run that test with the inputs > > and outputs for the assigned role. > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Monday, August 22, 2016 10:40 AM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Hi Tim, > > Maybe we can improve the Description, to mention UDP or other deatils? > > https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#sectio > > n- > > 4.1.4 > > > > Al > > > > > -----Original Message----- > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Monday, August 22, 2016 10:47 AM > > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > Al, > > > > > > I will say that when I looked at the first registry entry is was > > > difficult for me to understand what the actual test (ICMP ping, UDP > > > Echoplus) that was to be run for the action. > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Monday, August 22, 2016 8:05 AM > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > One point that has come up in IPPM discussion: > > > > > > The Fixed and Run Tine Parameters in the registry all have names, > > > but we may need to form a sub-registry to ensure that the names are > > > used consistently (among different registry entries, and in their > > > interpretation by other operations, e.g., as options in LMAP). > > > > > > IPPM agreed to continue with the IANA early review, and determine > > > the efficacy of the parameter sub-registry in those conversations > > > (on- going). > > > > > > Otherwise, I would like to hear what else is necessary (The IPPM > > > RFCs and Metric entries are not abstract, IMO). > > > > > > regards, > > > Al > > > > > > > -----Original Message----- > > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > > Sent: Sunday, August 21, 2016 8:58 PM > > > > To: Juergen Schoenwaelder > > > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > > > Subject: RE: [lmap] well known channel names > > > > > > > > Juergen, > > > > > > > > Indeed in the BBF we are thinking about the same thing (having own > > > > own > > > > registry) for non-measurement related tasks and diagnostic tasks > > > > that are not strictly associated with a metric (e.g., HTTP > Upload). > > > > These should be new charter items IMHO. > > > > > > > > I did think though IPPM would define the metrics sufficient enough > > > > that they would be self describing in that that they can be used > > > > directly as LMAP actions (including the actual test ala ICMP Ping) > > > > to > > > run. > > > > > > > > Looking at ietf-ippm-initial-registry (at least the first one in > > > > section > > > > 4) why do you think this is insufficient? > > > > > > > > I would like to hear Al's thoughts if he believes another registry > > > > is necessary for implementing IPPM entries as testable tasks. > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > university.de] > > > > Sent: Monday, August 15, 2016 7:54 AM > > > > To: Carey, Timothy (Nokia - US) > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] well known channel names > > > > > > > > Tim, > > > > > > > > I arrived at this conclusion because of two observations: > > > > > > > > (a) LMAP has tasks that are not measurement tasks (like a > reporting > > > > task) that will benefit of having some knowledge about common > > > > options; the metric registry does not apply to these > > > > non-measurement tasks (unless we start introducing pseudo > > > > metrics). > > > > > > > > (b) We have been struggling with the question to what extend the > > IPPM > > > > metric registry is expected to drive automation (e.g, does the > > > > IPPM registry define LMAP option names and how parameters are > > > > encoded as LMAP option values). > > > > > > > > If there would be an LMAP task registry, then the IPPM registry > > > > could focus on the abstract definition of metrics while the LMAP > > > > task registry would provide the binding to LMAP tasks, that is, > > > > how concrete tasks name use options etc to control the parameters > > > > defined > > > in IPPM metrics. > > > > The LMAP task metric would likely be read by tools while the IPPM > > > > metric would likely be read by code developers. For me, this > > > > started to look like a rather natural split of concerns. > > > > > > > > /js > > > > > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia - > > > > US) > > > > wrote: > > > > > Juergen, > > > > > > > > > > The text seems fine to me. > > > > > > > > > > As to the LMAP registry, I know in the BBF we also plan to have > > > > > a > > > > registry as well for some of the BBF specific tests and metrics. > > > > However we didn't think we should "wrapper" or "reference" the > > > > IPPM registry entries as they were suppose to be used directly in > LMAP. > > > > I'm not sure why you would think that would be needed? > > > > > > > > > > BR, > > > > > Tim > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > Sent: Friday, August 12, 2016 6:09 AM > > > > > To: lmap@ietf.org > > > > > Subject: [lmap] well known channel names > > > > > > > > > > Hi, > > > > > > > > > > here is an attempt to resolve the discussion around option > names. > > > > > > > > > > OLD > > > > > > > > > > While many of the Task Configuration Options are left to > > > individual > > > > > tasks to define, some common Options are used by multiple > > > > > tasks > > > and > > > > > benefit from standardisation: > > > > > > > > > > o Channel is used to specify the details of an endpoint for > > > > Control > > > > > or Reporting Task communications and is detailed elsewhere > > > > > in > > > > this > > > > > document. The common option name for specifying the > > > > > channel > > > is > > > > > "channel". > > > > > > > > > > NEW > > > > > > > > > > The ma-option-obj is used to define Task Configuration > Options. > > > > Task > > > > > Configuration Options are generally task specific. For tasks > > > > > associated with an entry in a registry, the registry may > > > > > define > > > > well- > > > > > known option names (e.g., the so-called parameters in the > > > > > IPPM > > > > metric > > > > > registry [I-D.ietf-ippm-metric-registry]). Control and > > Reporting > > > > > Tasks need to know the Channel they are going to use. The > > common > > > > > option name for specifying the channel is "channel" where the > > > > > option's value refers to the name of an ma-channel-obj. > > > > > > > > > > My intention was to explain more clearly that some of the option > > > > > names > > > > fall out of registries (e.g., the IPPM metric registry). I kept > > > > the definition of the well-known "channel" option name and I > > > > clarified that the value of this well-known option refers to the > > > > name of an > > > > ma-channel- obj. > > > > > > > > > > Personally, I would have preferred if we would not hard code any > > > > option names in the information model. I would rather have a > > > > simple LMAP task registry for (non-measurement) tasks that defines > > > > task specific parameters or options. This would give us the > > > > flexibility to define common non-measurement task options when we > > > > need them. But for the sake of wrapping this document up in a > > > > timely manner, I am willing to go along with the proposed text. > > > > > > > > > > That all said, I personally find the IPPM metry registry > > > > > somewhat difficult to work with. I could envision an approach > > > > > where we complement the IPPM metric registry with an LMAP task > > > > > registry that simply defines LMAP tasks, their functionality, > > > > > and their well-known options. For measurement tasks, this LMAP > > > > > task registry would refer to the IPPM metric registry which has > > > > > all the details for the differnet IPPM metrics. For > > > > > non-measurement tasks, the LMAP task registry would provide the > > > > > information necessary to use them in an interoperable manner, > > > > > such as the channel name or the flag whether empty reports > should be suppressed for report tasks. > > > > > In essence, such an LMAP task registry would consist of > > > > > > > > > > - a URI > > > > > - a short description > > > > > - an optional reference to a metric registry > > > > > - a list of well-known option names, each with a short > > > > > description > > > > > > > > > > and this would give us a well-known URI for identifying lets say > > > > > an > > > > LMAP reporting task that has well-known options and we would not > > > > need to hard-code anything in the information model. > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > > > > Fax: +49 421 200 3103 university.de/> > > > > > > > > > > > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Aug 22 12:04:51 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5212D813 for ; Mon, 22 Aug 2016 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 m_ozM1SwPpxV for ; Mon, 22 Aug 2016 12:04:20 -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 327FC12D7F3 for ; Mon, 22 Aug 2016 12:04:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00CDCAEA; Mon, 22 Aug 2016 21:04:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Sp0qqkJoZ1rJ; Mon, 22 Aug 2016 21:04:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 21:04:18 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E772E200AC; Mon, 22 Aug 2016 21:04:17 +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 jgqBwKRSPGFC; Mon, 22 Aug 2016 21:04:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B321200AB; Mon, 22 Aug 2016 21:04:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C8BB3C2CD65; Mon, 22 Aug 2016 21:04:14 +0200 (CEST) Date: Mon, 22 Aug 2016 21:04:13 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160822190411.GA14088@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" , "MORTON, ALFRED C (AL)" References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 19:04:29 -0000 On Mon, Aug 22, 2016 at 12:57:51AM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > Indeed in the BBF we are thinking about the same thing (having own own registry) for non-measurement related tasks and diagnostic tasks that are not strictly associated with a metric (e.g., HTTP Upload). > These should be new charter items IMHO. Exactly, there are LMAP tasks that do not implement a metric and that likely benefit from agreement on option names etc. > I did think though IPPM would define the metrics sufficient enough that they would be self describing in that that they can be used directly as LMAP actions (including the actual test ala ICMP Ping) to run. > > Looking at ietf-ippm-initial-registry (at least the first one in section 4) why do you think this is insufficient? > > I would like to hear Al's thoughts if he believes another registry is necessary for implementing IPPM entries as testable tasks. To be honest, I have trouble with the IPPM registry since it does not feel like a registry according to my expectations of a registry. ;-) Lets take section 4 "UDP Round-trip Latency Registry Entry" of draft-ietf-ippm-initial-registry-01 as an example: - This entry is ~8 pages of RFC text primarily targeting a human implementing the metric (and I note that the entry text is still incomplete). Why publish a specification of this size via IANA? - I still fail to see the need for N different identifiers (name, ID, URI, URL) [but this is really a very minor issue - I could get over it but since you asked... - It is still not clear what are option names and what are option values. Perhaps the idea is that runtime parameter names (such as 'Reciprocal_lambda') are LMAP option names but then I hardly know tools that use these kind of option names (perhaps my fault but in the world I am living in --reciprocal-lambda would be more common than Reciprocal_lambda). - The output data format description leaves me puzzled how data is encoded (Act_IP_UDP_Round-trip_Delay_Poisson_95th-percentile does not resolve to anything I can find in the document, likely a bug). Initially, the IPPM registry did not include a textual serialization of parameter values etc. Looking back, perhaps this was the right approach and we would overall benefit from separating the specification of metrics from the syntactic aspects of LMAP option names etc. For LMAP, I think we want a registry that is encoded in a format that is ready to drive tools (please recall the discussion we had to what extend the IPPM metric registry entry should be machine readable). This is another indicator for me that we would likely be better off separating concerns by having an IPPM metric registry focussed on _defining metrics_ and a separate LMAP task registry _defining LMAP tasks_. These two things are related but simply not the same. /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 Aug 22 12:08:45 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED4012D813 for ; Mon, 22 Aug 2016 12:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gHJaCqh5CYJE for ; Mon, 22 Aug 2016 12:08:41 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1FB12D807 for ; Mon, 22 Aug 2016 12:08:41 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id C2C32E4FAD998; Mon, 22 Aug 2016 19:08:38 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u7MJ8e0G013906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 19:08:40 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u7MJ6d39002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Aug 2016 19:08:40 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.59]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Aug 2016 15:08:24 -0400 From: "Carey, Timothy (Nokia - US)" To: "MORTON, ALFRED C (AL)" , Juergen Schoenwaelder Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3ggAABLhCAAAsKcIAAIPTwgAAITLA= Date: Mon, 22 Aug 2016 19:08:24 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A72B260@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62536@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598B62536@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 19:08:45 -0000 Al, Yes - but where is this configuration option normatively specified if not I= PPM? I am looking at this from the standpoint of a MA implementation. When I say= my MA has these Task capabilities (including registry entry and roles) for= the Task. That capability needs to include "tool(s)" used to implement met= ric. This is necessary for a controller to adequately configure the endpoi= nts. Maybe this is what Juergen meant by what is missing. If so then yes indeed= the LMAP registry entry is needed for instructions as well as housekeeping= tasks and the IPPM registry would NOT be directly referenced by LMAP agent= s - Juergen? BR, Tim -----Original Message----- From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]=20 Sent: Monday, August 22, 2016 1:42 PM To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder Cc: lmap@ietf.org Subject: RE: [lmap] well known channel names Hi Tim, Although ping is synonymous with sending ICMP echo requests, ping is a SW t= ool for controlling send/receive/results reporting. That's not just in my mind, it's in the *nix man pages: http://www.unix.com/man-page/linux/8/ping/=20 Let me try this as the explanation: The type of packets used in the measurement are specified in the metric reg= istry, so you will see IP/UDP in the entries now. We have a request to specify an IP/ICMP round trip time metric, TBD. But the metric registry is currently agnostic to the measurement control pr= otocol for arranging measurements between MAs or MA - MP (the IPPM RFCs for= metrics are agnostic too: they existed before OWAMP and TWAMP). So, specifying that the measurement is conducted using TWAMP, IPSLA, netper= f, some tool that launches DNS requests, or ping is a configuration option/= parameter that currently needs to be communicated in addition to the regist= ry entry. hope this helps, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy=20 > (Nokia - US) > Sent: Monday, August 22, 2016 12:46 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] well known channel names >=20 > Al, >=20 > I didn't anything referencing "SW tool" in this thread. >=20 > Is ICMP ping a SW tool in your mind? That is what I was referring to=20 > as a test. I certainly am not referring to LMAP as the test or SW=20 > tool in this thread. >=20 > For example in section 7 of the initial registry draft - infers TWAMP=20 > is the test used (yes I know it's a protocol). >=20 > I guess I should have said the protocol to use for the actual=20 > measurement.... For section 5 PDV what is the protocol to use for the=20 > actual measurement? >=20 > BR, > Tim >=20 >=20 >=20 > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 10:58 AM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names >=20 > Hi Tim, > When you say "actual test to run", are you referring to the software=20 > tool that would perform one role of the test? >=20 > When RFC2681 mentions ping, it also reminds the reader that the RT=20 > delay would be based on ICMP echo request/reply. > This is not the same measurement as the UDP RT Delay would measure,=20 > possibly for the reasons cited in section 2.6: >=20 > {Comment: "ping" would qualify as a round-trip measure under this > definition, with a Type-P of ICMP echo request/reply with 60-byte > packets. However, the uncertainties associated with a typical ping > program must be analyzed as in the next section, including the type > of reflecting point (a router may not handle an ICMP request in the > fast path) and effects of load on the reflecting point.} >=20 > Is "test" synonymous with SW tool below? > Al >=20 > > -----Original Message----- > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > Sent: Monday, August 22, 2016 11:47 AM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Al, > > > > I thought it would be in the method of measurement section. > > RFC 2681 doesn't explicitly call out the test that I could easily=20 > > find although it does say you can use ping. > > > > If we are explicit in the test actual test to run for the metric in=20 > > the method (or description) - I can then run that test with the=20 > > inputs and outputs for the assigned role. > > > > BR, > > Tim > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Monday, August 22, 2016 10:40 AM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Hi Tim, > > Maybe we can improve the Description, to mention UDP or other deatils? > > https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#sect > > io > > n- > > 4.1.4 > > > > Al > > > > > -----Original Message----- > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Monday, August 22, 2016 10:47 AM > > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > Al, > > > > > > I will say that when I looked at the first registry entry is was=20 > > > difficult for me to understand what the actual test (ICMP ping,=20 > > > UDP > > > Echoplus) that was to be run for the action. > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Monday, August 22, 2016 8:05 AM > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > One point that has come up in IPPM discussion: > > > > > > The Fixed and Run Tine Parameters in the registry all have names,=20 > > > but we may need to form a sub-registry to ensure that the names=20 > > > are used consistently (among different registry entries, and in=20 > > > their interpretation by other operations, e.g., as options in LMAP). > > > > > > IPPM agreed to continue with the IANA early review, and determine=20 > > > the efficacy of the parameter sub-registry in those conversations > > > (on- going). > > > > > > Otherwise, I would like to hear what else is necessary (The IPPM=20 > > > RFCs and Metric entries are not abstract, IMO). > > > > > > regards, > > > Al > > > > > > > -----Original Message----- > > > > From: Carey, Timothy (Nokia - US)=20 > > > > [mailto:timothy.carey@nokia.com] > > > > Sent: Sunday, August 21, 2016 8:58 PM > > > > To: Juergen Schoenwaelder > > > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > > > Subject: RE: [lmap] well known channel names > > > > > > > > Juergen, > > > > > > > > Indeed in the BBF we are thinking about the same thing (having=20 > > > > own own > > > > registry) for non-measurement related tasks and diagnostic tasks=20 > > > > that are not strictly associated with a metric (e.g., HTTP > Upload). > > > > These should be new charter items IMHO. > > > > > > > > I did think though IPPM would define the metrics sufficient=20 > > > > enough that they would be self describing in that that they can=20 > > > > be used directly as LMAP actions (including the actual test ala=20 > > > > ICMP Ping) to > > > run. > > > > > > > > Looking at ietf-ippm-initial-registry (at least the first one in=20 > > > > section > > > > 4) why do you think this is insufficient? > > > > > > > > I would like to hear Al's thoughts if he believes another=20 > > > > registry is necessary for implementing IPPM entries as testable tas= ks. > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-=20 > > > > university.de] > > > > Sent: Monday, August 15, 2016 7:54 AM > > > > To: Carey, Timothy (Nokia - US) > > > > Cc: lmap@ietf.org > > > > Subject: Re: [lmap] well known channel names > > > > > > > > Tim, > > > > > > > > I arrived at this conclusion because of two observations: > > > > > > > > (a) LMAP has tasks that are not measurement tasks (like a > reporting > > > > task) that will benefit of having some knowledge about common > > > > options; the metric registry does not apply to these > > > > non-measurement tasks (unless we start introducing pseudo > > > > metrics). > > > > > > > > (b) We have been struggling with the question to what extend the > > IPPM > > > > metric registry is expected to drive automation (e.g, does the > > > > IPPM registry define LMAP option names and how parameters are > > > > encoded as LMAP option values). > > > > > > > > If there would be an LMAP task registry, then the IPPM registry=20 > > > > could focus on the abstract definition of metrics while the LMAP=20 > > > > task registry would provide the binding to LMAP tasks, that is,=20 > > > > how concrete tasks name use options etc to control the=20 > > > > parameters defined > > > in IPPM metrics. > > > > The LMAP task metric would likely be read by tools while the=20 > > > > IPPM metric would likely be read by code developers. For me,=20 > > > > this started to look like a rather natural split of concerns. > > > > > > > > /js > > > > > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia=20 > > > > - > > > > US) > > > > wrote: > > > > > Juergen, > > > > > > > > > > The text seems fine to me. > > > > > > > > > > As to the LMAP registry, I know in the BBF we also plan to=20 > > > > > have a > > > > registry as well for some of the BBF specific tests and metrics. > > > > However we didn't think we should "wrapper" or "reference" the=20 > > > > IPPM registry entries as they were suppose to be used directly=20 > > > > in > LMAP. > > > > I'm not sure why you would think that would be needed? > > > > > > > > > > BR, > > > > > Tim > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > Sent: Friday, August 12, 2016 6:09 AM > > > > > To: lmap@ietf.org > > > > > Subject: [lmap] well known channel names > > > > > > > > > > Hi, > > > > > > > > > > here is an attempt to resolve the discussion around option > names. > > > > > > > > > > OLD > > > > > > > > > > While many of the Task Configuration Options are left to > > > individual > > > > > tasks to define, some common Options are used by multiple=20 > > > > > tasks > > > and > > > > > benefit from standardisation: > > > > > > > > > > o Channel is used to specify the details of an endpoint=20 > > > > > for > > > > Control > > > > > or Reporting Task communications and is detailed=20 > > > > > elsewhere in > > > > this > > > > > document. The common option name for specifying the=20 > > > > > channel > > > is > > > > > "channel". > > > > > > > > > > NEW > > > > > > > > > > The ma-option-obj is used to define Task Configuration > Options. > > > > Task > > > > > Configuration Options are generally task specific. For tasks > > > > > associated with an entry in a registry, the registry may=20 > > > > > define > > > > well- > > > > > known option names (e.g., the so-called parameters in the=20 > > > > > IPPM > > > > metric > > > > > registry [I-D.ietf-ippm-metric-registry]). Control and > > Reporting > > > > > Tasks need to know the Channel they are going to use. The > > common > > > > > option name for specifying the channel is "channel" where the > > > > > option's value refers to the name of an ma-channel-obj. > > > > > > > > > > My intention was to explain more clearly that some of the=20 > > > > > option names > > > > fall out of registries (e.g., the IPPM metric registry). I kept=20 > > > > the definition of the well-known "channel" option name and I=20 > > > > clarified that the value of this well-known option refers to the=20 > > > > name of an > > > > ma-channel- obj. > > > > > > > > > > Personally, I would have preferred if we would not hard code=20 > > > > > any > > > > option names in the information model. I would rather have a=20 > > > > simple LMAP task registry for (non-measurement) tasks that=20 > > > > defines task specific parameters or options. This would give us=20 > > > > the flexibility to define common non-measurement task options=20 > > > > when we need them. But for the sake of wrapping this document up=20 > > > > in a timely manner, I am willing to go along with the proposed text= . > > > > > > > > > > That all said, I personally find the IPPM metry registry=20 > > > > > somewhat difficult to work with. I could envision an approach=20 > > > > > where we complement the IPPM metric registry with an LMAP task=20 > > > > > registry that simply defines LMAP tasks, their functionality,=20 > > > > > and their well-known options. For measurement tasks, this LMAP=20 > > > > > task registry would refer to the IPPM metric registry which=20 > > > > > has all the details for the differnet IPPM metrics. For=20 > > > > > non-measurement tasks, the LMAP task registry would provide=20 > > > > > the information necessary to use them in an interoperable=20 > > > > > manner, such as the channel name or the flag whether empty=20 > > > > > reports > should be suppressed for report tasks. > > > > > In essence, such an LMAP task registry would consist of > > > > > > > > > > - a URI > > > > > - a short description > > > > > - an optional reference to a metric registry > > > > > - a list of well-known option names, each with a short=20 > > > > > description > > > > > > > > > > and this would give us a well-known URI for identifying lets=20 > > > > > say an > > > > LMAP reporting task that has well-known options and we would not=20 > > > > need to hard-code anything in the information model. > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > > > > Fax: +49 421 200 3103 university.de/> > > > > > > > > > > > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Aug 22 12:21:06 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABA312D825 for ; Mon, 22 Aug 2016 12:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 gerwlPKhiuRh for ; Mon, 22 Aug 2016 12:21:01 -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 D232312D80C for ; Mon, 22 Aug 2016 12:21:00 -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 0B01C121127; Mon, 22 Aug 2016 15:33:58 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 2D590E32C6; Mon, 22 Aug 2016 15:18:48 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Mon, 22 Aug 2016 15:21:00 -0400 From: "MORTON, ALFRED C (AL)" To: "Carey, Timothy (Nokia - US)" , Juergen Schoenwaelder Date: Mon, 22 Aug 2016 15:20:59 -0400 Thread-Topic: [lmap] well known channel names Thread-Index: AQHR9MvTSZq5CvXfkUqpjE/04u/N6KBFsquwgASO+YCACe2N0IAA0PdQgAAdgOCAAA9IEIAAAW3ggAABLhCAAAsKcIAAIPTwgAAITLCAAASoIA== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B6254C@NJFPSRVEXG0.research.att.com> References: <20160812110915.GC5685@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A7222B8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62536@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72B260@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72B260@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 22 Aug 2016 19:21:03 -0000 The metric Registry identifies *what* will be measured, and LMAP still needs to communicate the set of metrics that any tool/measurement system will measure and report. Most measurement tools can make lots of different measurements, with different size packets, different measurement durations, etc. The Metric registry entries narrow the choices for *any* measurement tool (compliant with the method of measurement in the entry), and specify how the results will be reported. I'm saying we need LMAP to communicate the set of metrics and the method (assuming the MA has more than one, and that may not be universally applicable, some MAs may have exactly one system/protocol to conduct measurements). Al > -----Original Message----- > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > Sent: Monday, August 22, 2016 3:08 PM > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names > > Al, > > Yes - but where is this configuration option normatively specified if > not IPPM? > > I am looking at this from the standpoint of a MA implementation. When I > say my MA has these Task capabilities (including registry entry and > roles) for the Task. That capability needs to include "tool(s)" used to > implement metric. This is necessary for a controller to adequately > configure the endpoints. > > Maybe this is what Juergen meant by what is missing. If so then yes > indeed the LMAP registry entry is needed for instructions as well as > housekeeping tasks and the IPPM registry would NOT be directly > referenced by LMAP agents - Juergen? > > BR, > Tim > > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Monday, August 22, 2016 1:42 PM > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: RE: [lmap] well known channel names > > Hi Tim, > > Although ping is synonymous with sending ICMP echo requests, ping is a > SW tool for controlling send/receive/results reporting. > That's not just in my mind, it's in the *nix man pages: > http://www.unix.com/man-page/linux/8/ping/ > > Let me try this as the explanation: > > The type of packets used in the measurement are specified in the metric > registry, so you will see IP/UDP in the entries now. > We have a request to specify an IP/ICMP round trip time metric, TBD. > But the metric registry is currently agnostic to the measurement control > protocol for arranging measurements between MAs or MA - MP (the IPPM > RFCs for metrics are agnostic too: they existed before OWAMP and TWAMP). > > So, specifying that the measurement is conducted using TWAMP, IPSLA, > netperf, some tool that launches DNS requests, or ping is a > configuration option/parameter that currently needs to be communicated > in addition to the registry entry. > > hope this helps, > Al > > > -----Original Message----- > > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy > > (Nokia - US) > > Sent: Monday, August 22, 2016 12:46 PM > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] well known channel names > > > > Al, > > > > I didn't anything referencing "SW tool" in this thread. > > > > Is ICMP ping a SW tool in your mind? That is what I was referring to > > as a test. I certainly am not referring to LMAP as the test or SW > > tool in this thread. > > > > For example in section 7 of the initial registry draft - infers TWAMP > > is the test used (yes I know it's a protocol). > > > > I guess I should have said the protocol to use for the actual > > measurement.... For section 5 PDV what is the protocol to use for the > > actual measurement? > > > > BR, > > Tim > > > > > > > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Monday, August 22, 2016 10:58 AM > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: RE: [lmap] well known channel names > > > > Hi Tim, > > When you say "actual test to run", are you referring to the software > > tool that would perform one role of the test? > > > > When RFC2681 mentions ping, it also reminds the reader that the RT > > delay would be based on ICMP echo request/reply. > > This is not the same measurement as the UDP RT Delay would measure, > > possibly for the reasons cited in section 2.6: > > > > {Comment: "ping" would qualify as a round-trip measure under this > > definition, with a Type-P of ICMP echo request/reply with 60-byte > > packets. However, the uncertainties associated with a typical ping > > program must be analyzed as in the next section, including the type > > of reflecting point (a router may not handle an ICMP request in the > > fast path) and effects of load on the reflecting point.} > > > > Is "test" synonymous with SW tool below? > > Al > > > > > -----Original Message----- > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > Sent: Monday, August 22, 2016 11:47 AM > > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > Al, > > > > > > I thought it would be in the method of measurement section. > > > RFC 2681 doesn't explicitly call out the test that I could easily > > > find although it does say you can use ping. > > > > > > If we are explicit in the test actual test to run for the metric in > > > the method (or description) - I can then run that test with the > > > inputs and outputs for the assigned role. > > > > > > BR, > > > Tim > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Monday, August 22, 2016 10:40 AM > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > Cc: lmap@ietf.org > > > Subject: RE: [lmap] well known channel names > > > > > > Hi Tim, > > > Maybe we can improve the Description, to mention UDP or other > deatils? > > > https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-01#sect > > > io > > > n- > > > 4.1.4 > > > > > > Al > > > > > > > -----Original Message----- > > > > From: Carey, Timothy (Nokia - US) [mailto:timothy.carey@nokia.com] > > > > Sent: Monday, August 22, 2016 10:47 AM > > > > To: MORTON, ALFRED C (AL); Juergen Schoenwaelder > > > > Cc: lmap@ietf.org > > > > Subject: RE: [lmap] well known channel names > > > > > > > > Al, > > > > > > > > I will say that when I looked at the first registry entry is was > > > > difficult for me to understand what the actual test (ICMP ping, > > > > UDP > > > > Echoplus) that was to be run for the action. > > > > > > > > BR, > > > > Tim > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Monday, August 22, 2016 8:05 AM > > > > To: Carey, Timothy (Nokia - US); Juergen Schoenwaelder > > > > Cc: lmap@ietf.org > > > > Subject: RE: [lmap] well known channel names > > > > > > > > One point that has come up in IPPM discussion: > > > > > > > > The Fixed and Run Tine Parameters in the registry all have names, > > > > but we may need to form a sub-registry to ensure that the names > > > > are used consistently (among different registry entries, and in > > > > their interpretation by other operations, e.g., as options in > LMAP). > > > > > > > > IPPM agreed to continue with the IANA early review, and determine > > > > the efficacy of the parameter sub-registry in those conversations > > > > (on- going). > > > > > > > > Otherwise, I would like to hear what else is necessary (The IPPM > > > > RFCs and Metric entries are not abstract, IMO). > > > > > > > > regards, > > > > Al > > > > > > > > > -----Original Message----- > > > > > From: Carey, Timothy (Nokia - US) > > > > > [mailto:timothy.carey@nokia.com] > > > > > Sent: Sunday, August 21, 2016 8:58 PM > > > > > To: Juergen Schoenwaelder > > > > > Cc: lmap@ietf.org; MORTON, ALFRED C (AL) > > > > > Subject: RE: [lmap] well known channel names > > > > > > > > > > Juergen, > > > > > > > > > > Indeed in the BBF we are thinking about the same thing (having > > > > > own own > > > > > registry) for non-measurement related tasks and diagnostic tasks > > > > > that are not strictly associated with a metric (e.g., HTTP > > Upload). > > > > > These should be new charter items IMHO. > > > > > > > > > > I did think though IPPM would define the metrics sufficient > > > > > enough that they would be self describing in that that they can > > > > > be used directly as LMAP actions (including the actual test ala > > > > > ICMP Ping) to > > > > run. > > > > > > > > > > Looking at ietf-ippm-initial-registry (at least the first one in > > > > > section > > > > > 4) why do you think this is insufficient? > > > > > > > > > > I would like to hear Al's thoughts if he believes another > > > > > registry is necessary for implementing IPPM entries as testable > tasks. > > > > > > > > > > BR, > > > > > Tim > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > > > university.de] > > > > > Sent: Monday, August 15, 2016 7:54 AM > > > > > To: Carey, Timothy (Nokia - US) > > > > > Cc: lmap@ietf.org > > > > > Subject: Re: [lmap] well known channel names > > > > > > > > > > Tim, > > > > > > > > > > I arrived at this conclusion because of two observations: > > > > > > > > > > (a) LMAP has tasks that are not measurement tasks (like a > > reporting > > > > > task) that will benefit of having some knowledge about > common > > > > > options; the metric registry does not apply to these > > > > > non-measurement tasks (unless we start introducing pseudo > > > > > metrics). > > > > > > > > > > (b) We have been struggling with the question to what extend the > > > IPPM > > > > > metric registry is expected to drive automation (e.g, does > the > > > > > IPPM registry define LMAP option names and how parameters > are > > > > > encoded as LMAP option values). > > > > > > > > > > If there would be an LMAP task registry, then the IPPM registry > > > > > could focus on the abstract definition of metrics while the LMAP > > > > > task registry would provide the binding to LMAP tasks, that is, > > > > > how concrete tasks name use options etc to control the > > > > > parameters defined > > > > in IPPM metrics. > > > > > The LMAP task metric would likely be read by tools while the > > > > > IPPM metric would likely be read by code developers. For me, > > > > > this started to look like a rather natural split of concerns. > > > > > > > > > > /js > > > > > > > > > > On Fri, Aug 12, 2016 at 07:21:48PM +0000, Carey, Timothy (Nokia > > > > > - > > > > > US) > > > > > wrote: > > > > > > Juergen, > > > > > > > > > > > > The text seems fine to me. > > > > > > > > > > > > As to the LMAP registry, I know in the BBF we also plan to > > > > > > have a > > > > > registry as well for some of the BBF specific tests and metrics. > > > > > However we didn't think we should "wrapper" or "reference" the > > > > > IPPM registry entries as they were suppose to be used directly > > > > > in > > LMAP. > > > > > I'm not sure why you would think that would be needed? > > > > > > > > > > > > BR, > > > > > > Tim > > > > > > > > > > > > -----Original Message----- > > > > > > From: Juergen Schoenwaelder > > > > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > > > > Sent: Friday, August 12, 2016 6:09 AM > > > > > > To: lmap@ietf.org > > > > > > Subject: [lmap] well known channel names > > > > > > > > > > > > Hi, > > > > > > > > > > > > here is an attempt to resolve the discussion around option > > names. > > > > > > > > > > > > OLD > > > > > > > > > > > > While many of the Task Configuration Options are left to > > > > individual > > > > > > tasks to define, some common Options are used by multiple > > > > > > tasks > > > > and > > > > > > benefit from standardisation: > > > > > > > > > > > > o Channel is used to specify the details of an endpoint > > > > > > for > > > > > Control > > > > > > or Reporting Task communications and is detailed > > > > > > elsewhere in > > > > > this > > > > > > document. The common option name for specifying the > > > > > > channel > > > > is > > > > > > "channel". > > > > > > > > > > > > NEW > > > > > > > > > > > > The ma-option-obj is used to define Task Configuration > > Options. > > > > > Task > > > > > > Configuration Options are generally task specific. For > tasks > > > > > > associated with an entry in a registry, the registry may > > > > > > define > > > > > well- > > > > > > known option names (e.g., the so-called parameters in the > > > > > > IPPM > > > > > metric > > > > > > registry [I-D.ietf-ippm-metric-registry]). Control and > > > Reporting > > > > > > Tasks need to know the Channel they are going to use. The > > > common > > > > > > option name for specifying the channel is "channel" where > the > > > > > > option's value refers to the name of an ma-channel-obj. > > > > > > > > > > > > My intention was to explain more clearly that some of the > > > > > > option names > > > > > fall out of registries (e.g., the IPPM metric registry). I kept > > > > > the definition of the well-known "channel" option name and I > > > > > clarified that the value of this well-known option refers to the > > > > > name of an > > > > > ma-channel- obj. > > > > > > > > > > > > Personally, I would have preferred if we would not hard code > > > > > > any > > > > > option names in the information model. I would rather have a > > > > > simple LMAP task registry for (non-measurement) tasks that > > > > > defines task specific parameters or options. This would give us > > > > > the flexibility to define common non-measurement task options > > > > > when we need them. But for the sake of wrapping this document up > > > > > in a timely manner, I am willing to go along with the proposed > text. > > > > > > > > > > > > That all said, I personally find the IPPM metry registry > > > > > > somewhat difficult to work with. I could envision an approach > > > > > > where we complement the IPPM metric registry with an LMAP task > > > > > > registry that simply defines LMAP tasks, their functionality, > > > > > > and their well-known options. For measurement tasks, this LMAP > > > > > > task registry would refer to the IPPM metric registry which > > > > > > has all the details for the differnet IPPM metrics. For > > > > > > non-measurement tasks, the LMAP task registry would provide > > > > > > the information necessary to use them in an interoperable > > > > > > manner, such as the channel name or the flag whether empty > > > > > > reports > > should be suppressed for report tasks. > > > > > > In essence, such an LMAP task registry would consist of > > > > > > > > > > > > - a URI > > > > > > - a short description > > > > > > - an optional reference to a metric registry > > > > > > - a list of well-known option names, each with a short > > > > > > description > > > > > > > > > > > > and this would give us a well-known URI for identifying lets > > > > > > say an > > > > > LMAP reporting task that has well-known options and we would not > > > > > need to hard-code anything in the information model. > > > > > > > > > > > > /js > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > > Germany > > > > > > Fax: +49 421 200 3103 > university.de/> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > > > > Fax: +49 421 200 3103 university.de/> > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Aug 22 12:21:11 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D7612D80C for ; Mon, 22 Aug 2016 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 KLCyJhyM7mhi for ; Mon, 22 Aug 2016 12:21:03 -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 8A86112D81B for ; Mon, 22 Aug 2016 12:21:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6022DA96; Mon, 22 Aug 2016 21:21:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4Jvst-AFstRT; Mon, 22 Aug 2016 21:20:57 +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, 22 Aug 2016 21:21:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B208200AD; Mon, 22 Aug 2016 21:21:00 +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 xps1NXfKo2v5; Mon, 22 Aug 2016 21:20:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57351200AB; Mon, 22 Aug 2016 21:20:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1457F3C2CF26; Mon, 22 Aug 2016 21:20:57 +0200 (CEST) Date: Mon, 22 Aug 2016 21:20:55 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20160822192052.GA14172@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20160815125359.GA17225@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A72A430@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624CC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72ACBA@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B624FC@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AEF3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62505@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72AFD3@US70UWXCHMBA05.zam.alcatel-lucent.com> <4AF73AA205019A4C8A1DDD32C034631D4598B62536@NJFPSRVEXG0.research.att.com> <9966516C6EB5FC4381E05BF80AA55F77012A72B260@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A72B260@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "MORTON, ALFRED C \(AL\)" , "lmap@ietf.org" Subject: Re: [lmap] well known channel names X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 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, 22 Aug 2016 19:21:05 -0000 On Mon, Aug 22, 2016 at 07:08:24PM +0000, Carey, Timothy (Nokia - US) wrote: > Al, > > Yes - but where is this configuration option normatively specified if not IPPM? > > I am looking at this from the standpoint of a MA implementation. When I say my MA has these Task capabilities (including registry entry and roles) for the Task. That capability needs to include "tool(s)" used to implement metric. This is necessary for a controller to adequately configure the endpoints. > > Maybe this is what Juergen meant by what is missing. If so then yes indeed the LMAP registry entry is needed for instructions as well as housekeeping tasks and the IPPM registry would NOT be directly referenced by LMAP agents - Juergen? > I believe it is simpler to separate concerns. a) IPPM cares about precise definitions of metrics. This is goodness. Their primary target are humans, not tools. b) LMAP is concernd about tasks, their options, etc. LMAP prefers to have machine readable information that can drive tools. Merging both aspects into a single registry may be feasible in theory, but it seems difficult in practice. And we would end up with corner cases like LMAP tasks that are not implementing metrics (unless we start creating ugly pseudo IPPM metrics since all we have is a single registry). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Aug 23 08:42:26 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC612D185 for ; Tue, 23 Aug 2016 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC4WMcEQbdjj for ; Tue, 23 Aug 2016 08:42:23 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BA712D579 for ; Tue, 23 Aug 2016 08:39:21 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id w38so42939861qtb.0 for ; Tue, 23 Aug 2016 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Fq52ZoRx32+juVQhGbt5qXhT1/CMJ5+zyJYUYqsQ11c=; b=d80Zf1um+dUfYJk+u1nMewFaXZ+wr0msBF1VntUdhoGWBDFUgMbC6depJGQ4V9UnEm UbtGXcDAZqlQaPxBC6DXN30v8y3mRKDtKsAX+e3sGEu1+uPxXZdo5UALG90lVrMeMDXi FbiZlEpQlq1TVlLbEiSRzV6nt0rg/k0spVrKetP9BmLr2Ol34y9wN233yUIJisoqAQVs sqO1MEgetiCsiE8tB6tQPuHUU/Jv7za6zHqPqjIWzU01Vhyply7a1JWX6UYMPJbt/Kf8 HI9D7xMJDPKON4fPA+jaYdk1k1UlPDoboihz0OpubKEyrR+xzGbsUXRK019rR7XPRjwB ribQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Fq52ZoRx32+juVQhGbt5qXhT1/CMJ5+zyJYUYqsQ11c=; b=CcipKcEEK3RqmuXlydBRPhH2bg0UQlfNtsBGvgspBaC+/19SPZUMtVWP06WzVJTKoq 5B6b0tux7hDIABoEwsz2KWe8hQ9gPmmmL7/0EujjRY4v2Juhtj84nlLCi/hBrmjexZme fAc8MQ8sCUDjNGmJaD02ihi+tvNYQZYKCIGks7VBNYc/rWXEXn3663e77Gw4Jmjj+AiH Wc8S8t+9Eoh4ZQoLApibVcLGTjMpsqmrbL9+Uel2u71cf975YNpxJLjjfyNCeyJFYabb 7vgvDUyL/g2YkVkkxuEpPeVg3zxfVsk372VEGqJI9zrndUCajP1B2y4dgW/96Pc1kc8A eXAw== X-Gm-Message-State: AEkooutj0yfXjRYiR/N5GisZOtiOmCCCFXnRwMLPfrbZvGrOd1J/g+sgaPDhnCRu+kqAcmESppPGEkgKK4CvRw== X-Received: by 10.237.37.216 with SMTP id y24mr30456032qtc.58.1471966760414; Tue, 23 Aug 2016 08:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.107.67 with HTTP; Tue, 23 Aug 2016 08:39:19 -0700 (PDT) In-Reply-To: <20160823.144636.1796310931546236457.mbj@tail-f.com> References: <20160823.144636.1796310931546236457.mbj@tail-f.com> From: Dan Romascanu Date: Tue, 23 Aug 2016 18:39:19 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11407030e03435053abef7e3 Archived-At: Subject: [lmap] Fwd: YANG doctor review of draft-ietf-lmap-yang-05 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: 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, 23 Aug 2016 15:42:25 -0000 --001a11407030e03435053abef7e3 Content-Type: text/plain; charset=UTF-8 The YANG doctor review by Martin Bjorklund. Regards, Dan ---------- Forwarded message ---------- From: Martin Bjorklund Date: Tue, Aug 23, 2016 at 3:46 PM Subject: YANG doctor review of draft-ietf-lmap-yang-05 To: draft-ietf-lmap-yang.all@ietf.org Cc: yang-doctors@ietf.org Hi, I am the assigned YANG doctor for this document. I have reviewed this document from a pure YANG standpoint. I have not checked that the YANG model matches the information model etc. As expected, this model is in good shape. Here are my comments: o The typedef glob-pattern use \ in a double qouted string. Specifically, it uses the characters \\ which actually expand to a single '\'. Also in YANG 1.1 the sequences \* and \? are illegal. I suggest this text is re-written to avoid backslahses, or that a single quote string is used. o The device-id is of type inet:uri. I see that this is specified in the information model as well. But why is it a URI? As an operator, which URI should I choose? o lmap/agent/device-id's description says: The device-id identifies a property of the device running the measurement agent. Should this be s/a property of//? Otherwise, which property is being referred to? o lmap-state/agent/device-id is marked as 'mandatory true', but its description says that is optional. o lmap/agent/controller-timeout says that "an event is raised". What kind of event? Which protocol? [later] Ok, reading the events subtree, I see that there is an event 'controller-lost' there. Presumably the text refers to this event. If so, this text could maybe be clarified. o In /lmap/events/event/event-type there are a couple of cases that are leaf empty, and these leafs are marked as 'mandatory true': case immediate { leaf immediate { type empty; mandatory true; ... } } I was going to write that this is confusing, but in fact it is pretty clever! No action required! o Should the choice /lmap/events/event/event-type be marked as 'mandatory true'? Otherwise, what happens if no event-type is configured? o The descriptions in several nodes in /lmap/events/event/event-type/calendar are a bit confusing: leaf-list month { type lmap:month-or-all; min-elements 1; description "A month at which this calendar timing will trigger. The wildcard means all months."; The description says "_A_ month", but the node is a leaf-list. Maybe change to "A set of months". (same for other nodes in this case as well) o /lmap/tasks/task/program is optional (and marked as nacm:default-deny-write). What happens if this leaf is not set? o Are /lmap-state/agent/{hardware,firmware} different than /system-state/platform/{machine,os-release/os-version} in ietf-system? o So the MA is supposed to invoke RPCs on a controller. Is this described somewhere? Are the details left to implementations? /martin --001a11407030e03435053abef7e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The YANG doctor review by Martin Bjorklund.
=
Regards,

Dan

---------- Forwarded message ----------
From: Martin Bjorklund <mbj@tail-f.com>
Date: Tue, Aug 23, 2016 at= 3:46 PM
Subject: YANG doctor review of draft-ietf-lmap-yang-05
To: <= a href=3D"mailto:draft-ietf-lmap-yang.all@ietf.org">draft-ietf-lmap-yang.al= l@ietf.org
Cc: yang-doctors= @ietf.org


Hi,

I am the assigned YANG doctor for this document.=C2=A0 I have reviewed this=
document from a pure YANG standpoint.=C2=A0 I have not checked that the
YANG model matches the information model etc.

As expected, this model is in good shape.=C2=A0 Here are my comments:


o=C2=A0 The typedef glob-pattern use \ in a double qouted string.
=C2=A0 =C2=A0Specifically, it uses the characters \\ which actually expand = to a
=C2=A0 =C2=A0single '\'.=C2=A0 Also in YANG 1.1 the sequences \* an= d \?=C2=A0 are illegal.

=C2=A0 =C2=A0I suggest this text is re-written to avoid backslahses, or tha= t a
=C2=A0 =C2=A0single quote string is used.


o=C2=A0 The device-id is of type inet:uri.=C2=A0 I see that this is specifi= ed in
=C2=A0 =C2=A0the information model as well.=C2=A0 But why is it a URI?=C2= =A0 As an
=C2=A0 =C2=A0operator, which URI should I choose?


o=C2=A0 lmap/agent/device-id's description says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The device-id identifies a propert= y of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device running the measurement age= nt.

=C2=A0 =C2=A0Should this be s/a property of//?=C2=A0 Otherwise, which prope= rty is
=C2=A0 =C2=A0being referred to?


o=C2=A0 lmap-state/agent/device-id is marked as 'mandatory true', b= ut its
=C2=A0 =C2=A0description says that is optional.


o=C2=A0 lmap/agent/controller-timeout says that "an event is raised&qu= ot;.=C2=A0 What
=C2=A0 =C2=A0kind of event?=C2=A0 Which protocol?=C2=A0 [later] Ok, reading= the events
=C2=A0 =C2=A0subtree, I see that there is an event 'controller-lost'= ; there.
=C2=A0 =C2=A0Presumably the text refers to this event.=C2=A0 If so, this te= xt could
=C2=A0 =C2=A0maybe be clarified.


o=C2=A0 In /lmap/events/event/event-type there are a couple of cases that =C2=A0 =C2=A0are leaf empty, and these leafs are marked as 'mandatory t= rue':

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case immediate {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf immediate {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type empty;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0I was going to write that this is confusing, but in fact it is=
=C2=A0 =C2=A0pretty clever!=C2=A0 No action required!


o=C2=A0 Should the choice /lmap/events/event/event-type be marked as
=C2=A0 =C2=A0'mandatory true'?=C2=A0 =C2=A0Otherwise, what happens = if no event-type is
=C2=A0 =C2=A0configured?


o=C2=A0 The descriptions in several nodes in
=C2=A0 =C2=A0/lmap/events/event/event-type/calendar are a bit confusin= g:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list month {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type lmap:month-or-= all;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 min-elements 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "A mont= h at which this calendar timing will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trigge= r. The wildcard means all months.";

=C2=A0 =C2=A0The description says "_A_ month", but the node is a = leaf-list.
=C2=A0 =C2=A0Maybe change to "A set of months".=C2=A0 (same for o= ther nodes in this
=C2=A0 =C2=A0case as well)


o=C2=A0 /lmap/tasks/task/program is optional (and marked as
=C2=A0 =C2=A0nacm:default-deny-write).

=C2=A0 =C2=A0What happens if this leaf is not set?


o=C2=A0 Are /lmap-state/agent/{hardware,firmware} different than
=C2=A0 =C2=A0/system-state/platform/{machine,os-release/os-version} in=
=C2=A0 =C2=A0ietf-system?


o=C2=A0 So the MA is supposed to invoke RPCs on a controller.=C2=A0 Is this=
=C2=A0 =C2=A0described somewhere?=C2=A0 Are the details left to implementat= ions?



/martin

--001a11407030e03435053abef7e3-- From nobody Wed Aug 31 01:12:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0312D9E8 for ; Wed, 31 Aug 2016 01:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlZ8eXmeTwJ1 for ; Wed, 31 Aug 2016 01:12:30 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F9712D9DE for ; Wed, 31 Aug 2016 01:12:30 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id v123so43591606qkh.2 for ; Wed, 31 Aug 2016 01:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ofbhnuP+x6Ic0ipj21myLUV6KBLgCch4yeUos8OLTn8=; b=q978xBNr3800yBY6sxHJ255ctSOamEtDY2P9yc2yct39A8se6tQXBw+Eb9HZB0UzXH nS24n45IpMbtVbNul1bHA3d3jO7+QAZCeRON5v4F72Gd4Gx88XWeiHR3rmJhDjQihimx K4ubPcKazw8pruOOC94WYVjQExCUjSwl3v7B4IMMTedR1+0/tmUzqyIKTeuvkg5fX3Xs WVJbOsiYDdxN4j5N5NhPOodxPRxpKsHCFTS9rfUknrJ62ixDI/h71FIAoCMwi0BLk2SX Jxh/WGdwDGUUj3vGkkuyhbxOaarcuTVdlbEZGngX+vIYtQCBedEsOzerG6Oc6n45ttFO YXeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ofbhnuP+x6Ic0ipj21myLUV6KBLgCch4yeUos8OLTn8=; b=bSDjV4lNhqvKFAUedxcnib6XC/bP3bCdRB2ZcHUICLwUJmkfZGbdXZp4z6tA5oqtH+ LMyGcVn260wIa1KJxJOQimqHaWaVProORmjMN8FQ+08PUpurOGKUCyQtTAEXHZ45o8l3 vvzuVLGvxCW1K5Xo5EoozzHio3DoILkgz4BwaF4j71IrvFuHKau6Khh0RfJtkXDYp001 hxefq7hlBvKY6gad0xcL0MJXTMJaPNZA3ksJ7dyaPJFciCg5jaq7pTx6lbCoFacpw6Zf y3YzZ6r8f7961VDb+NaMRtZ0op+CDcjikRRX1pTio70/XDbBCll5WYt9bZbF5UyvWcIG JnuQ== X-Gm-Message-State: AE9vXwME+4pKumFy3v8mDJ3+rjCrUvoypwvpNPT6ZwSIjP42hiPAOrvKttvtR/H6jjbPuTRnf+oN1Ix0AH3m2g== X-Received: by 10.55.23.208 with SMTP id 77mr9126794qkx.252.1472631149024; Wed, 31 Aug 2016 01:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.107.67 with HTTP; Wed, 31 Aug 2016 01:12:28 -0700 (PDT) From: Dan Romascanu Date: Wed, 31 Aug 2016 11:12:28 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11479e2e85df0b053b59a816 Archived-At: Subject: [lmap] NomCom 2016-2017: Call for Nominations X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 08:12:32 -0000 --001a11479e2e85df0b053b59a816 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The NomCom process is ongoing. Please help NomCom in this important task. Thanks and Regards, Dan -----Original Message----- From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair 2016 Sent: Monday, August 29, 2016 4:37 PM To: Working Group Chairs Subject: NomCom 2016-2017: Call for Nominations Please forward on to your Working Groups - The 2016-17 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2016. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2016/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2016 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2016/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom-16@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available on September 2, 2016 and have a submission deadline of October 13, 2016. NomCom 2016-17 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark th= e field we won=E2=80=99t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 8, 2016. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Lou Berger IAB Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler* Suzanne Woolf IESG Jari Arkko (GEN)* Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2016/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2016/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-16@ietf.org. Thank you for your help in identifying qualified nominees! Lucy Lynch Nomcom Chair 2016-17 nomcom-chair-2016@ietf.org llynch@civil-tongue.net --001a11479e2e85df0b053b59a816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The NomCom process is ongoing. Please help NomCo= m in this important task.

Thanks and Regards,

Da= n


-----Original Message-----
From: WGChairs [mailto:wgchair= s-bounces@ietf.org] On Behalf Of NomCom Chair 2016
Sent: Monday, August 29, 2016 4:37 PM
To: Working Group Chairs
Subject: NomCom 2016-2017: Call for Nominations

Please forward on to your Working Groups -

The 2016-17 Nominating Committee (Nomcom) is seeking nominations from
now until October 8, 2016. The open positions being considered by thi= s
year's Nomcom can be found at the end of this email and also on this year's Nomcom website:

https://datatracker.ietf.org/nomcom/2016/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2016 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2016/nomi= nate/

=C2=A0 {Note that nominations made using the web tool require an ietf.org
=C2=A0 =C2=A0datatracker account. You can create a datatracker ietf.org account =C2=A0 =C2=A0if you don't have one already by visiting the following UR= L:
=C2=A0 =C2=A0https://datatracker.ietf.org/accounts= /create/ }

If you are unable to use the web form, nominations may instead be made
by email to nomcom-16@ietf.org. I= f using email, please include the word
"Nominate" in the Subject and indicate in the email who is being<= br> nominated, their email address (to confirm acceptance of the
nomination), and the position for which you are making the nomination.
If you are nominating someone other than yourself, please tell us if
we may tell the nominee that you were the one who made the nomination.
If you wish to nominate someone via email for more than one position,
please use separate emails to do so.

Self-nomination is welcome!

Willing nominees will be asked to fill out a questionnaire
specific to the position for which they are nominated.=C2=A0 The questionna= ires
will be available on September 2, 2016 and have a submission deadli= ne of
October = 13, 2016.

NomCom 2016-17 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in BCP 10/RFC 7437.=C2=A0 As stated in RFC 7437: &= quot;The
list of nominees willing to be considered for positions under review
in the current Nomcom cycle is not confidential". Willing nominees for=
each position will be listed in a publicly accessible way - anyone
with a datatracker account may access the lists.=C2=A0 Additionally, the nomination form asks if we may share your own name with the
nominee. In all other ways, the confidentiality requirements of BCP10
remain in effect.=C2=A0 All feedback and all Nomcom deliberations will
remain confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the Nomcom
to tell the nominee that you were the one who made the
nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mar= k the field
we won=E2=80=99t tell.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
NomCom on or before October 8, 2016.

Please submit your nominations as early as possible for the sake of
your nominees. Note that nominations should not wait for management
permission, as it is easier to decline the nomination than put one in
late.

The Nomcom appoints individuals to fill the open slots on the IAOC,
the IAB, and the IESG. The list of people and posts whose terms end
with the March 2017 IETF meeting, and thus the positions for which
this Nomcom is responsible, follows:

IAOC

=C2=A0 =C2=A0 Lou Berger

IAB

=C2=A0 =C2=A0 Ralph Droms*
=C2=A0 =C2=A0 Russ Housley*
=C2=A0 =C2=A0 Robert Sparks
=C2=A0 =C2=A0 Andrew Sullivan
=C2=A0 =C2=A0 Dave Thaler*
=C2=A0 =C2=A0 Suzanne Woolf

IESG

=C2=A0 =C2=A0 Jari Arkko (GEN)*
=C2=A0 =C2=A0 Deborah Brungard (RTG)
=C2=A0 =C2=A0 Ben Campbell (ART)
=C2=A0 =C2=A0 Spencer Dawkins (TSV)
=C2=A0 =C2=A0 Stephen Farrell (SEC)*
=C2=A0 =C2=A0 Joel Jaeggli (OPS)*
=C2=A0 =C2=A0 Terry Manderson (INT)
=C2=A0 =C2=A0 Alvaro Retana (RTG)

*- have indicated that they do not intend to accept a
renomination. This information is always up to date on
https://datatracker.ietf.org/nomcom/2016/

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF, and also, please consider accepting a nomination.=C2=A0 You'l= l
find extensive information about specific positions, developed by the
IAB, IESG, and IAOC, under individual tabs at:

=C2=A0 https://datatracker.ietf.org/nomco= m/2016/requirements/

In addition to nominations, the Nomcom seeks community input on the
positions themselves.=C2=A0 We need and welcome the community's views a= nd
input on the jobs within each organization. If you have ideas on the
positions' responsibilities (more, less, different), please let us
know.

Please send suggestions and feedback about this to nomcom-16@ietf.org.

Thank you for your help in identifying qualified nominees!

Lucy Lynch
Nomcom Chair 2016-17
nomcom-chair-2016@ietf.org
llynch@civil-tongue.net
--001a11479e2e85df0b053b59a816-- From nobody Wed Aug 31 08:56:00 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6910212D1E7 for ; Wed, 31 Aug 2016 08:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: 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_I1SJWy9fY7 for ; Wed, 31 Aug 2016 08:55:54 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF14C12D63C for ; Wed, 31 Aug 2016 08:49:27 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so55690105qkc.0 for ; Wed, 31 Aug 2016 08:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=C4NfAibgec0KxJvM00/svd7/w/Ix0VAO0voHD6KikI4=; b=QS0Pzb8jsPAfP87WATuV4DRX2AYHnN0NVhqPeEDSWwAEyQu9CyxjoQo9DrMR1Wg2HS Q2/kPhNxZM16qzvk79nXxb//AL5BmIDaGJD1ayIVu2vJgy/68lIJzJMcZUszScKKWTF0 9QNW20bXWxuvDOj+DC5ozRS/eYnONlTr+FfK1AYLEuBurAcwfPtI6c0M6YrhhWspXi7v USW6nIe97nkVNZyj8jx0Q/XNu1EXcz32sd+I/JamDbKB2zn6kVe3qPd6sxeHFGvecGnz wIz9uxDw8WfeFJjpmKfh3foTWhb+2j13r0JW1KPLAmHztCN+OImCQSsIGx3STdy3XSnO /CxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C4NfAibgec0KxJvM00/svd7/w/Ix0VAO0voHD6KikI4=; b=ktoKw62pTvv3d0iID/WbqaMZQsxjrCEbNFmzWax/EyCQSEgLdzcEHPSuzyPcM8ErWB oC8IzFbJobr95rc8IHpW90Zn/pf03/VQ78IywVloJ+1JNRO7XDd0Xf6kQfO+9YTZ2PG7 1+iSuEdAYa5bfzbmO5K1/rHggV8cxBHktlTJSM6kK8kO0vZTr1FmL9EeoJAZ9IL57pgz LvkX+tg9C7yfeNSqWJY1xzDKH0M2AoDdTmVJHcFxiSpRWFm9F1DnqQm/i4O0uwaruoxa dkSIlW4tqGefqy61RgRBIRMF2knTVdV7hhUQWw3ToNyJY9dZpm1ZvaKUq7/wJtUatTQC ookw== X-Gm-Message-State: AE9vXwPmsb5C0zj1rhM9V1uUos05t8Lq28WEze6tj1LvehP0mvsQVANMQIWAaosaAn6RojZMwpfU0zw/LMmh6A== X-Received: by 10.55.68.66 with SMTP id r63mr11103992qka.81.1472658566595; Wed, 31 Aug 2016 08:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.107.67 with HTTP; Wed, 31 Aug 2016 08:49:26 -0700 (PDT) From: Dan Romascanu Date: Wed, 31 Aug 2016 18:49:26 +0300 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11489df8bce508053b600aa3 Archived-At: Subject: [lmap] wg status and way ahead X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:56:00 -0000 --001a11489df8bce508053b600aa3 Content-Type: text/plain; charset=UTF-8 Hi, We (the chairs) had a conference call with our AD (Alissa) today to discuss WG status and next steps. Here are the main points. - in Berlin we agreed to submit revised versions of the information model and data model I-Ds and send them to a second WGLC. The IM I-D was submitted. Juergen, can you update the WG on the status of the DM model? - 2nd WGLC - to be run in September. - we shall plan for a virtual interim - target dates 10/5, 10/6, 10/7, or 10/10. You shall see soon a doodle poll from Jason; if unnecessary we shall cancel - we shall plan for a 90 min meeting at IETF 97; if unnecessary we shall cancel - we want to have the documents reviewed by a broader constituency; please use your contacts to send them to review to operators in the different communities (e.g. cable access industry) or regulators. we shall also request an early OPS-DIR review Please answer and comment on this plan. Regards, Jason and Dan --001a11489df8bce508053b600aa3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

<= /div>We (the chairs) had a conference call with our AD (Alissa) today to di= scuss WG status and next steps. Here are the main points.

- i= n Berlin we agreed to submit revised versions of the information model and = data model I-Ds and send them to a second WGLC. The IM I-D was submitted. J= uergen, can you update the WG on the status of the DM model?
- 2n= d WGLC - to be run in September.=C2=A0
- we shall plan for a virt= ual interim - target dates 10/5, 10/6, 10/7, or 10/10. You shall see soon a= doodle poll from Jason; if unnecessary we shall cancel
- we shall= plan for a 90 min meeting at IETF 97; if unnecessary we shall cancel
- we want to have the documents reviewed by a broader constituency; ple= ase use your contacts to send them to review to operators in the different = communities (e.g. cable access industry) or regulators. we shall also reque= st an early OPS-DIR review

Please answer and comment on this p= lan.

Regards,

Jason and Dan


--001a11489df8bce508053b600aa3-- From nobody Wed Aug 31 10:45:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03EF12D576 for ; Wed, 31 Aug 2016 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 Upd4PerfZMKQ for ; Wed, 31 Aug 2016 10:45:31 -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 39F4512D592 for ; Wed, 31 Aug 2016 10:45:31 -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 E8BB0121289; Wed, 31 Aug 2016 13:58:55 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id ADB08E044C; Wed, 31 Aug 2016 13:43:08 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 31 Aug 2016 13:45:27 -0400 From: "MORTON, ALFRED C (AL)" To: Dan Romascanu , "lmap@ietf.org" Date: Wed, 31 Aug 2016 13:45:26 -0400 Thread-Topic: [lmap] wg status and way ahead Thread-Index: AdIDoDHpDL9bExXLSxy+/+h87uWO8QADoYYA Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B62AE5@NJFPSRVEXG0.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: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D4598B62AE5NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] wg status and way ahead X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:45:33 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62AE5NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuIGFuZCBKYXNvbiwgdGhhbmtzIGZvciB0aGUgY3VycmVudCBzdGF0dXMuDQoNCk92ZXIg dGhpcyBXR+KAmXMgbGlmZSBzcGFuLCB3ZeKAmXZlIHNlZW4gc2V2ZXJhbCBkcmFmdHMgdGhhdA0K cHJvcG9zZWQgdG8gc3RhcnQgd29yayB3aGljaCB3YXMgYmV5b25kIExNQVDigJlzIGN1cnJlbnQN CmNoYXJ0ZXIuIE5vIG9uZSBoYXMgc3Bva2VuIHVwIGZvciB0aGVzZSBpZGVhcyByZWNlbnRseS4N Cg0KUGVyaGFwcyBpdOKAmXMgd29ydGh3aGlsZSB0byBjb25zaWRlciByZS1jaGFydGVyaW5nIGFu eXdheToNCnRoZXJlIG1heSBiZSBzb21lIG9sZC9uZXcvYXR0cmFjdGl2ZSBwcm9wb3NhbHMgdGhh dCBjb21lDQpmb3J3YXJkLCBnaXZlbiB0aGUgb3Bwb3J0dW5pdHkuDQoNCnJlZ2FyZHMsDQpBbA0K DQpGcm9tOiBsbWFwIFttYWlsdG86bG1hcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RGFuIFJvbWFzY2FudQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMTE6NDkgQU0N ClRvOiBsbWFwQGlldGYub3JnDQpTdWJqZWN0OiBbbG1hcF0gd2cgc3RhdHVzIGFuZCB3YXkgYWhl YWQNCg0KSGksDQpXZSAodGhlIGNoYWlycykgaGFkIGEgY29uZmVyZW5jZSBjYWxsIHdpdGggb3Vy IEFEIChBbGlzc2EpIHRvZGF5IHRvIGRpc2N1c3MgV0cgc3RhdHVzIGFuZCBuZXh0IHN0ZXBzLiBI ZXJlIGFyZSB0aGUgbWFpbiBwb2ludHMuDQotIGluIEJlcmxpbiB3ZSBhZ3JlZWQgdG8gc3VibWl0 IHJldmlzZWQgdmVyc2lvbnMgb2YgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGFuZCBkYXRhIG1vZGVs IEktRHMgYW5kIHNlbmQgdGhlbSB0byBhIHNlY29uZCBXR0xDLiBUaGUgSU0gSS1EIHdhcyBzdWJt aXR0ZWQuIEp1ZXJnZW4sIGNhbiB5b3UgdXBkYXRlIHRoZSBXRyBvbiB0aGUgc3RhdHVzIG9mIHRo ZSBETSBtb2RlbD8NCi0gMm5kIFdHTEMgLSB0byBiZSBydW4gaW4gU2VwdGVtYmVyLg0KLSB3ZSBz aGFsbCBwbGFuIGZvciBhIHZpcnR1YWwgaW50ZXJpbSAtIHRhcmdldCBkYXRlcyAxMC81LCAxMC82 LCAxMC83LCBvciAxMC8xMC4gWW91IHNoYWxsIHNlZSBzb29uIGEgZG9vZGxlIHBvbGwgZnJvbSBK YXNvbjsgaWYgdW5uZWNlc3Nhcnkgd2Ugc2hhbGwgY2FuY2VsDQotIHdlIHNoYWxsIHBsYW4gZm9y IGEgOTAgbWluIG1lZXRpbmcgYXQgSUVURiA5NzsgaWYgdW5uZWNlc3Nhcnkgd2Ugc2hhbGwgY2Fu Y2VsDQotIHdlIHdhbnQgdG8gaGF2ZSB0aGUgZG9jdW1lbnRzIHJldmlld2VkIGJ5IGEgYnJvYWRl ciBjb25zdGl0dWVuY3k7IHBsZWFzZSB1c2UgeW91ciBjb250YWN0cyB0byBzZW5kIHRoZW0gdG8g cmV2aWV3IHRvIG9wZXJhdG9ycyBpbiB0aGUgZGlmZmVyZW50IGNvbW11bml0aWVzIChlLmcuIGNh YmxlIGFjY2VzcyBpbmR1c3RyeSkgb3IgcmVndWxhdG9ycy4gd2Ugc2hhbGwgYWxzbyByZXF1ZXN0 IGFuIGVhcmx5IE9QUy1ESVIgcmV2aWV3DQpQbGVhc2UgYW5zd2VyIGFuZCBjb21tZW50IG9uIHRo aXMgcGxhbi4NClJlZ2FyZHMsDQpKYXNvbiBhbmQgRGFuDQoNCg== --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62AE5NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+SGkgRGFuIGFuZCBKYXNvbiwgdGhhbmtzIGZvciB0 aGUgY3VycmVudCBzdGF0dXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPk92ZXIgdGhpcyBXR+KAmXMgbGlmZSBzcGFuLCB3ZeKAmXZlIHNlZW4g c2V2ZXJhbCBkcmFmdHMgdGhhdCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPnByb3Bvc2VkIHRvIHN0YXJ0IHdvcmsgd2hpY2ggd2FzIGJleW9uZCBM TUFQ4oCZcyBjdXJyZW50IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+Y2hhcnRlci4gTm8gb25lIGhhcyBzcG9rZW4gdXAgZm9yIHRoZXNlIGlkZWFz IHJlY2VudGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz5QZXJoYXBzIGl04oCZcyB3b3J0aHdoaWxlIHRvIGNvbnNpZGVyIHJlLWNoYXJ0ZXJp bmcgYW55d2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+dGhlcmUgbWF5IGJlIHNvbWUgb2xkL25ldy9hdHRyYWN0aXZlIHByb3Bvc2FscyB0aGF0 IGNvbWUgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNr Jz5mb3J3YXJkLCBnaXZlbiB0aGUgb3Bwb3J0dW5pdHkuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5BbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGxt YXAgW21haWx0bzpsbWFwLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RGFu IFJvbWFzY2FudTxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMTE6 NDkgQU08YnI+PGI+VG86PC9iPiBsbWFwQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBbbG1h cF0gd2cgc3RhdHVzIGFuZCB3YXkgYWhlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2 PjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+SGksIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPldlICh0aGUgY2hhaXJz KSBoYWQgYSBjb25mZXJlbmNlIGNhbGwgd2l0aCBvdXIgQUQgKEFsaXNzYSkgdG9kYXkgdG8gZGlz Y3VzcyBXRyBzdGF0dXMgYW5kIG5leHQgc3RlcHMuIEhlcmUgYXJlIHRoZSBtYWluIHBvaW50cy4g PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0gaW4gQmVybGluIHdlIGFn cmVlZCB0byBzdWJtaXQgcmV2aXNlZCB2ZXJzaW9ucyBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWwg YW5kIGRhdGEgbW9kZWwgSS1EcyBhbmQgc2VuZCB0aGVtIHRvIGEgc2Vjb25kIFdHTEMuIFRoZSBJ TSBJLUQgd2FzIHN1Ym1pdHRlZC4gSnVlcmdlbiwgY2FuIHlvdSB1cGRhdGUgdGhlIFdHIG9uIHRo ZSBzdGF0dXMgb2YgdGhlIERNIG1vZGVsPyA8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+LSAybmQgV0dMQyAtIHRvIGJlIHJ1biBpbiBTZXB0ZW1iZXIuJm5ic3A7IDxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tIHdlIHNoYWxsIHBsYW4gZm9yIGEg dmlydHVhbCBpbnRlcmltIC0gdGFyZ2V0IGRhdGVzIDEwLzUsIDEwLzYsIDEwLzcsIG9yIDEwLzEw LiBZb3Ugc2hhbGwgc2VlIHNvb24gYSBkb29kbGUgcG9sbCBmcm9tIEphc29uOyBpZiB1bm5lY2Vz c2FyeSB3ZSBzaGFsbCBjYW5jZWw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+LSB3ZSBzaGFsbCBwbGFuIGZvciBhIDkwIG1pbiBtZWV0aW5nIGF0IElFVEYgOTc7IGlmIHVu bmVjZXNzYXJ5IHdlIHNoYWxsIGNhbmNlbDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPi0gd2Ugd2FudCB0byBoYXZlIHRo ZSBkb2N1bWVudHMgcmV2aWV3ZWQgYnkgYSBicm9hZGVyIGNvbnN0aXR1ZW5jeTsgcGxlYXNlIHVz ZSB5b3VyIGNvbnRhY3RzIHRvIHNlbmQgdGhlbSB0byByZXZpZXcgdG8gb3BlcmF0b3JzIGluIHRo ZSBkaWZmZXJlbnQgY29tbXVuaXRpZXMgKGUuZy4gY2FibGUgYWNjZXNzIGluZHVzdHJ5KSBvciBy ZWd1bGF0b3JzLiB3ZSBzaGFsbCBhbHNvIHJlcXVlc3QgYW4gZWFybHkgT1BTLURJUiByZXZpZXc8 bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz5QbGVhc2UgYW5zd2VyIGFuZCBjb21tZW50IG9uIHRoaXMgcGxhbi48bzpwPjwv bzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz5SZWdhcmRzLCA8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5KYXNvbiBhbmQgRGFuPGJyPjxicj48bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62AE5NJFPSRVEXG0re_-- From nobody Wed Aug 31 11:52:56 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF912D69A for ; Wed, 31 Aug 2016 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=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 LKq6iyYJtiiL for ; Wed, 31 Aug 2016 11:52:53 -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 C1DC512D68B for ; Wed, 31 Aug 2016 11:52:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C2E1CDA; Wed, 31 Aug 2016 20:52:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PLQUWcVESGdc; Wed, 31 Aug 2016 20:52:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 31 Aug 2016 20:52:50 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B261A200A7; Wed, 31 Aug 2016 20:52:50 +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 ko0NqCqP5afT; Wed, 31 Aug 2016 20:52:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A8DA200A5; Wed, 31 Aug 2016 20:52:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E3103C55D1D; Wed, 31 Aug 2016 20:52:47 +0200 (CEST) Date: Wed, 31 Aug 2016 20:52:47 +0200 From: Juergen Schoenwaelder To: Dan Romascanu Message-ID: <20160831185246.GB4834@elstar.local> Mail-Followup-To: Dan Romascanu , 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.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] wg status and way ahead X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 18:52:54 -0000 On Wed, Aug 31, 2016 at 06:49:26PM +0300, Dan Romascanu wrote: > Hi, > > We (the chairs) had a conference call with our AD (Alissa) today to discuss > WG status and next steps. Here are the main points. > > - in Berlin we agreed to submit revised versions of the information model > and data model I-Ds and send them to a second WGLC. The IM I-D was > submitted. Juergen, can you update the WG on the status of the DM model? > - 2nd WGLC - to be run in September. There was a discussion around an lmap task registry and it might be useful to get to some conclusions or directions. Right now, the information model is not very consistent. In some parts, you find phrases like This includes registry entries for the task and any configuration parameters" or Both measurement and non-measurement Tasks have registry entries to enable the MA to uniquely identify the Task it should execute and retrieve the schema for any parameters that may be passed to the Task. while at other places you find text that is restricting registry things specifically to metric registries, e.g. Tasks and actions can be associated with entries in a metrics registry. It seems that the older text was more generic registry text and I think the newer text that talks specifically about metric registries should be aligned to allow for other registries. This also includes renaming ma-metric-registry- to ma-registry-. If we can settle this, I can prepare -12 of the information model relatively quickly and then this should be ready for the 2nd WG last call. For the data model, there is more editing work needed to align it with the information model and to go through Martin's review comments. I guess it is a day of editing work. I can try to squeeze this into next week (but knowing the direction whether we forsee to support other registries would help with that as well). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 31 12:35:24 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043FC12D6B3 for ; Wed, 31 Aug 2016 12:35:24 -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 autolearn_force=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 32kJuoP58Ghk for ; Wed, 31 Aug 2016 12:35:22 -0700 (PDT) Received: from mail.chartercom.com (mail.chartercom.com [24.176.92.28]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CB712D0BD for ; Wed, 31 Aug 2016 12:35:21 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.30,263,1470718800"; d="scan'208,217"; a="37769077" Received: from unknown (HELO SC58MEXGP010.CORP.CHARTERCOM.com) ([172.24.253.138]) by mail.chartercom.com with ESMTP; 31 Aug 2016 14:33:49 -0500 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM (172.24.253.136) by SC58MEXGP010.CORP.CHARTERCOM.com (172.24.253.138) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 31 Aug 2016 14:35:20 -0500 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM ([fe80::719f:6d16:1ed5:5b5c]) by SC58MEXGP008.CORP.CHARTERCOM.com ([fe80::719f:6d16:1ed5:5b5c%19]) with mapi id 15.00.1104.000; Wed, 31 Aug 2016 14:35:20 -0500 From: "Weil, Jason A" To: "lmap@ietf.org" Thread-Topic: Virtual Interim Meeting Poll Thread-Index: AQHSA77PVAJjCR4wUEWbyBdYh5W6AQ== Date: Wed, 31 Aug 2016 19:35:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.253.243] Content-Type: multipart/alternative; boundary="_000_D3ECA8985D241jasonweilchartercom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Virtual Interim Meeting Poll X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:35:24 -0000 --_000_D3ECA8985D241jasonweilchartercom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LMAP Participants, Please take a few minutes to fill out the poll at the link provided for a p= otential virtual meeting before IETF 97. If there are a number of West Coas= t USA participants interested in attending let me know and I will add an 11= 00EST option. http://doodle.com/poll/hw8shm3g4h42s7gy Thanks, Jason From: lmap > on behalf = of Dan Romascanu > Date: Wednesday, August 31, 2016 at 9:49 AM To: "lmap@ietf.org" > Subject: [lmap] wg status and way ahead Resent-From: Jason Weil > Hi, We (the chairs) had a conference call with our AD (Alissa) today to discuss= WG status and next steps. Here are the main points. - in Berlin we agreed to submit revised versions of the information model a= nd data model I-Ds and send them to a second WGLC. The IM I-D was submitted= . Juergen, can you update the WG on the status of the DM model? - 2nd WGLC - to be run in September. - we shall plan for a virtual interim - target dates 10/5, 10/6, 10/7, or 1= 0/10. You shall see soon a doodle poll from Jason; if unnecessary we shall = cancel - we shall plan for a 90 min meeting at IETF 97; if unnecessary we shall ca= ncel - we want to have the documents reviewed by a broader constituency; please = use your contacts to send them to review to operators in the different comm= unities (e.g. cable access industry) or regulators. we shall also request a= n early OPS-DIR review Please answer and comment on this plan. Regards, Jason and Dan --_000_D3ECA8985D241jasonweilchartercom_ Content-Type: text/html; charset="us-ascii" Content-ID: <01466874F7811D49B2F6268BA9FCB457@chartercom.com> Content-Transfer-Encoding: quoted-printable
LMAP Participants,

Please take a few minutes to fill out the poll at the link provided fo= r a potential virtual meeting before IETF 97. If there are a number of West= Coast USA participants interested in attending let me know and I will add = an 1100EST option.


Thanks,
Jason

From: lmap <lmap-bounces@ietf.org> on behalf of Dan Romasca= nu <dromasca@gmail.com>
Date: Wednesday, August 31, 2016 at= 9:49 AM
To: "lmap@ietf.org" <lmap@i= etf.org>
Subject: [lmap] wg status and way a= head
Resent-From: Jason Weil <jason.weil@twcable.com>

Hi,

We (the chairs) had a conference call with our AD (Alissa) today to discuss= WG status and next steps. Here are the main points.

- in Berlin we agreed to submit revised versions of the information model a= nd data model I-Ds and send them to a second WGLC. The IM I-D was submitted= . Juergen, can you update the WG on the status of the DM model?
- 2nd WGLC - to be run in September. 
- we shall plan for a virtual interim - target dates 10/5, 10/6, 10/7, or 1= 0/10. You shall see soon a doodle poll from Jason; if unnecessary we shall = cancel
- we shall plan for a 90 min meeting at IETF 97; if unnecessary we shall ca= ncel
- we want to have the documents reviewed by a broader constituency; please = use your contacts to send them to review to operators in the different comm= unities (e.g. cable access industry) or regulators. we shall also request a= n early OPS-DIR review

Please answer and comment on this plan.

Regards,

Jason and Dan


 --_000_D3ECA8985D241jasonweilchartercom_-- From nobody Wed Aug 31 12:45:32 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0E012D761 for ; Wed, 31 Aug 2016 12:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-VRcazt7DGj for ; Wed, 31 Aug 2016 12:45:28 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E6612D75B for ; Wed, 31 Aug 2016 12:45:28 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 11so18472785qtc.0 for ; Wed, 31 Aug 2016 12:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jss0og0cJw9Ag2UXYIo5IWkNvWHFLWOyFTaIpxses74=; b=q7CfpRkd2jlQq8a8pzI6YgAg9PYU3ovSueqe7pY4lynpNFwBu/BP+zTGh2ZUp5WkeD s6Q24GGugHDmvgiBTsuKZAzN/OdtJ0/1ahzNb6g2HOaR5O1URgOHBn+GGLzStcXHkBec lQFhskqJTSdWkB5g/QcF8+ILonR93c7L3GVk4vKIa+ntTjYl9tjvAt1NoerJOC3AQDpL Q95uqw0HLumqJ5tJSZoHli5weoO7zLsKAoWeA26L4Kqvt0Dg93ozH0o6+7kGltMClfgE RkzZWXaEB4BD0gzIX3JS7GD8qyr5kmX6XcM+ew8WNYsN+/ABA7FRYKOC1ejkqNaHjU7q ZF2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jss0og0cJw9Ag2UXYIo5IWkNvWHFLWOyFTaIpxses74=; b=boKVCecgBdJC0zu04kudhKwcsrb9Z+/gaOWSzr8sgLaGeB5f0Im/UKswCYAMWLTIT3 ptzuYc2aRcaA/UZvLaG5brxLso2SG5kw20+BUufyPQZh24hOz0q6WjZUoZLwJgZZGACj boO2hJpdgrCY0KaAx4VdnHS5kuafgANBDPUMys8k3YJF0saZsijCSUaHVxXR0epquzVi 3D8CuuPRBZM/4al2RqJ841p1Rwj1rU5ZUXYZtw+Ddb+UsRw8/1bVYv0XRvpoW1tZ4TGI mRhQR+weZSvEcAocYtO+MaMfITTNdr4irw6jgJFq73ambsvktv/nvKNL2XqzTBqtzvmJ 8qcw== X-Gm-Message-State: AE9vXwPUk9+HZF/5g/bRx1wcGz/ojOiqn2YsaZZejfL3Cziray6mKCIgHi+2fgOgk4nNm3dYWtG+S3j3pS6zFA== X-Received: by 10.237.37.216 with SMTP id y24mr12932735qtc.58.1472672726523; Wed, 31 Aug 2016 12:45:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.107.67 with HTTP; Wed, 31 Aug 2016 12:45:25 -0700 (PDT) In-Reply-To: <20160831185246.GB4834@elstar.local> References: <20160831185246.GB4834@elstar.local> From: Dan Romascanu Date: Wed, 31 Aug 2016 22:45:25 +0300 Message-ID: To: Juergen Schoenwaelder , Dan Romascanu , lmap@ietf.org Content-Type: multipart/alternative; boundary=001a11407030bc25c6053b635658 Archived-At: Subject: Re: [lmap] wg status and way ahead X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:45:30 -0000 --001a11407030bc25c6053b635658 Content-Type: text/plain; charset=UTF-8 Hi Juergen, (speaking as contributor) Does really the text point to a restriction? Tasks and actions can be associated with entries in a metrics registry. It does not say 'ONLY with entries in a metrics registry'. Maybe the current text is OK, but what is missing is a clarification. I agree about the need for renaming. Regards, Dan On Wed, Aug 31, 2016 at 9:52 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Aug 31, 2016 at 06:49:26PM +0300, Dan Romascanu wrote: > > Hi, > > > > We (the chairs) had a conference call with our AD (Alissa) today to > discuss > > WG status and next steps. Here are the main points. > > > > - in Berlin we agreed to submit revised versions of the information model > > and data model I-Ds and send them to a second WGLC. The IM I-D was > > submitted. Juergen, can you update the WG on the status of the DM model? > > - 2nd WGLC - to be run in September. > > There was a discussion around an lmap task registry and it might be > useful to get to some conclusions or directions. Right now, the > information model is not very consistent. In some parts, you find > phrases like > > This includes registry entries for the task and any configuration > parameters" > > or > > Both measurement and non-measurement Tasks have registry entries > to enable the MA to uniquely identify the Task it should execute > and retrieve the schema for any parameters that may be passed to > the Task. > > while at other places you find text that is restricting registry > things specifically to metric registries, e.g. > > Tasks and actions can be associated with entries in a metrics > registry. > > It seems that the older text was more generic registry text and I > think the newer text that talks specifically about metric registries > should be aligned to allow for other registries. This also includes > renaming ma-metric-registry- to ma-registry-. > If we can settle this, I can prepare -12 of the information model > relatively quickly and then this should be ready for the 2nd WG last > call. > > For the data model, there is more editing work needed to align it with > the information model and to go through Martin's review comments. I > guess it is a day of editing work. I can try to squeeze this into next > week (but knowing the direction whether we forsee to support other > registries would help with that as well). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11407030bc25c6053b635658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

(sp= eaking as contributor)

Does really the text point to a restric= tion?

=C2=A0 =C2=A0 Tasks and actions can be associated with entrie= s in a metrics
=C2=A0 =C2=A0 registry.

It does not say 'ONLY with entries= in a metrics registry'. Maybe the current text is OK, but what is miss= ing is a clarification.

I agree about the need for renaming. =

Regards,

Dan

<= br>
On Wed, Aug 31, 2016 at 9:52 PM, Juergen Scho= enwaelder <j.schoenwaelder@jacobs-university.de>= wrote:
On Wed, A= ug 31, 2016 at 06:49:26PM +0300, Dan Romascanu wrote:
> Hi,
>
> We (the chairs) had a conference call with our AD (Alissa) today to di= scuss
> WG status and next steps. Here are the main points.
>
> - in Berlin we agreed to submit revised versions of the information mo= del
> and data model I-Ds and send them to a second WGLC. The IM I-D was
> submitted. Juergen, can you update the WG on the status of the DM mode= l?
> - 2nd WGLC - to be run in September.

There was a discussion around an lmap task registry and it might be<= br> useful to get to some conclusions or directions. Right now, the
information model is not very consistent. In some parts, you find
phrases like

=C2=A0 =C2=A0 This includes registry entries for the task and any configura= tion
=C2=A0 =C2=A0 parameters"

or

=C2=A0 =C2=A0 Both measurement and non-measurement Tasks have registry entr= ies
=C2=A0 =C2=A0 to enable the MA to uniquely identify the Task it should exec= ute
=C2=A0 =C2=A0 and retrieve the schema for any parameters that may be passed= to
=C2=A0 =C2=A0 the Task.

while at other places you find text that is restricting registry
things specifically to metric registries, e.g.

=C2=A0 =C2=A0 Tasks and actions can be associated with entries in a metrics=
=C2=A0 =C2=A0 registry.

It seems that the older text was more generic registry text and I
think the newer text that talks specifically about metric registries
should be aligned to allow for other registries. This also includes
renaming ma-metric-registry-<something> to ma-registry-<something&= gt;.
If we can settle this, I can prepare -12 of the information model
relatively quickly and then this should be ready for the 2nd WG last
call.

For the data model, there is more editing work needed to align it with
the information model and to go through Martin's review comments. I
guess it is a day of editing work. I can try to squeeze this into next
week (but knowing the direction whether we forsee to support other
registries would help with that as well).

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a11407030bc25c6053b635658-- From nobody Wed Aug 31 12:49:33 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A034B12D770 for ; Wed, 31 Aug 2016 12:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBXzZa8hcug0 for ; Wed, 31 Aug 2016 12:49:30 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51FD12D76D for ; Wed, 31 Aug 2016 12:49:29 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id l2so62948574qkf.3 for ; Wed, 31 Aug 2016 12:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EnZsP3ehZlWCtxeK1VE4la82QzzPeAGuseSXAKpbd0c=; b=Wzi3DkKbqZWcVfAA81Y29TzzR2r/myzSFdvFB5cHkv+0lA9siIeMsvvzfaTnCzRsND B3QKy0RYYIrG6tS5J+Tf5XMfuv+ijV+EmsbcPY14ty7kuLT/DbD7eYQpxK+JXwVcQG1v 9dYWMQlp0Fqx0Pb6dQDQb3jocrh6GNUjqmOF8b/X0bSZBuXNZBT69PPwBRtGJvU1pVnX N+xvcsKYkreeWQUhg6AJwH69DuXamf3WUdQ2A38KCW91iVSpGS8MWbJfWgq3god21IAK wuwl+lXqDtxnZTU099ETzj7lLvSCoJ/IE71x2aI92OlgrbXcj2QW7oYBHFsUDIl3ycEL i93w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EnZsP3ehZlWCtxeK1VE4la82QzzPeAGuseSXAKpbd0c=; b=b3XkHG7lh/LY5VhGV/qRbZroWvSC70DzNGyU5rVFJnaUKq/P5v55/GBMbFYUD5p3he B8l3YvKpJTq9gxIABcPch5uICjJQohTs8CINYn1eDSLqhFKlL5Re8T0kRRwcJH3TnSKk /XjasCicfn5o74HUkCy7Tx8m6yNiobSxLg43YfyyVZPR7RKzrNLSKWpgLRmrFpppecQt q0jnla9XdFPG1Dq+0tIWv0vMVc6UWhp8XyhI0I4GzmTmxVqryr3NRKgog8hfOLiGXg/H Oadfr5Jn6O/0B8Ldic222aEWM6EHk+IzP6EyYpeqCpsX6EqFxSFRuA9ClsQv0NGa3Sf6 akiQ== X-Gm-Message-State: AE9vXwPS85ZuVRiLQM77rx2uucR4nXGOu86zOXnCaQFiPteQptxciPb1zYzGr/dso0QsQiwdUMYeS3mXNbNOkg== X-Received: by 10.55.31.85 with SMTP id f82mr345083qkf.213.1472672968846; Wed, 31 Aug 2016 12:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.107.67 with HTTP; Wed, 31 Aug 2016 12:49:28 -0700 (PDT) In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598B62AE5@NJFPSRVEXG0.research.att.com> References: <4AF73AA205019A4C8A1DDD32C034631D4598B62AE5@NJFPSRVEXG0.research.att.com> From: Dan Romascanu Date: Wed, 31 Aug 2016 22:49:28 +0300 Message-ID: To: "MORTON, ALFRED C (AL)" Content-Type: multipart/alternative; boundary=001a1147b3ae2dd577053b63651e Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] wg status and way ahead X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:49:31 -0000 --001a1147b3ae2dd577053b63651e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Al, As we said in the meeting at IETF 96 - now it's the time to discuss proposals for old or new items for re-chartering. The floor is open. What we miss is contributions, i.e. Internet-Drafts. But hey, it's still only August 31st in my time zone. Regards, Dan On Wed, Aug 31, 2016 at 8:45 PM, MORTON, ALFRED C (AL) wrote: > Hi Dan and Jason, thanks for the current status. > > > > Over this WG=E2=80=99s life span, we=E2=80=99ve seen several drafts that > > proposed to start work which was beyond LMAP=E2=80=99s current > > charter. No one has spoken up for these ideas recently. > > > > Perhaps it=E2=80=99s worthwhile to consider re-chartering anyway: > > there may be some old/new/attractive proposals that come > > forward, given the opportunity. > > > > regards, > > Al > > > > *From:* lmap [mailto:lmap-bounces@ietf.org] *On Behalf Of *Dan Romascanu > *Sent:* Wednesday, August 31, 2016 11:49 AM > *To:* lmap@ietf.org > *Subject:* [lmap] wg status and way ahead > > > > Hi, > > We (the chairs) had a conference call with our AD (Alissa) today to > discuss WG status and next steps. Here are the main points. > > - in Berlin we agreed to submit revised versions of the information model > and data model I-Ds and send them to a second WGLC. The IM I-D was > submitted. Juergen, can you update the WG on the status of the DM model? > > - 2nd WGLC - to be run in September. > > - we shall plan for a virtual interim - target dates 10/5, 10/6, 10/7, or > 10/10. You shall see soon a doodle poll from Jason; if unnecessary we sha= ll > cancel > > - we shall plan for a 90 min meeting at IETF 97; if unnecessary we shall > cancel > > - we want to have the documents reviewed by a broader constituency; pleas= e > use your contacts to send them to review to operators in the different > communities (e.g. cable access industry) or regulators. we shall also > request an early OPS-DIR review > > Please answer and comment on this plan. > > Regards, > > Jason and Dan > > --001a1147b3ae2dd577053b63651e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Al,

As we said in the meet= ing at IETF 96 - now it's the time to discuss proposals for old or new = items for re-chartering. The floor is open. What we miss is contributions, = i.e. Internet-Drafts. But hey, it's still only August 31st in my time z= one.

Regards,

Dan


On Wed, Aug 31, 2016 at 8:45 PM, M= ORTON, ALFRED C (AL) <acmorton@att.com> wrote:

Hi Dan and Jason, thanks for the current stat= us.

=C2=A0

Over this WG=E2=80=99s life span,= we=E2=80=99ve seen several drafts that

proposed to start work which was beyond LMAP=E2=80=99s= current

charter. No = one has spoken up for these ideas recently.

=C2=A0

Perhaps it=E2=80=99s worthwhile to consider re-chartering anyway:=

there may be some old/ne= w/attractive proposals that come

forward, given the opportunity.

=C2=A0

regards,

Al=

=C2=A0

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Dan Romasca= nu
Sent: Wednesday, August 31, 2016 11:49 AM
To: lmap@ietf.org
Subjec= t: [lmap] wg status and way ahead

<= div>

=C2=A0

<= div>

Hi,

We (the chairs) had a conference call with ou= r AD (Alissa) today to discuss WG status and next steps. Here are the main = points.

- in Berlin we agree= d to submit revised versions of the information model and data model I-Ds a= nd send them to a second WGLC. The IM I-D was submitted. Juergen, can you u= pdate the WG on the status of the DM model?

- 2nd WGLC - to be run in September.=C2=A0

- we shall plan for a virtual interim - targ= et dates 10/5, 10/6, 10/7, or 10/10. You shall see soon a doodle poll from = Jason; if unnecessary we shall cancel

- we shall plan for a 90 min meeting at IETF 97; if unnecessary we= shall cancel

- we want to have the documents reviewed by a broader const= ituency; please use your contacts to send them to review to operators in th= e different communities (e.g. cable access industry) or regulators. we shal= l also request an early OPS-DIR review

Please answer and comment on this = plan.

Regards,

Jason and Dan


--001a1147b3ae2dd577053b63651e-- From nobody Wed Aug 31 12:50:35 2016 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7427F12D746 for ; Wed, 31 Aug 2016 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=unavailable autolearn_force=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 uh2ODy42BzjZ for ; Wed, 31 Aug 2016 12:50:32 -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 AEEE912D762 for ; Wed, 31 Aug 2016 12:42:39 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id AFA02120A3F; Wed, 31 Aug 2016 15:56:04 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 5E2C8F034B; Wed, 31 Aug 2016 15:42:39 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 31 Aug 2016 15:42:39 -0400 From: "MORTON, ALFRED C (AL)" To: "Weil, Jason A" , "lmap@ietf.org" Date: Wed, 31 Aug 2016 15:42:37 -0400 Thread-Topic: Virtual Interim Meeting Poll Thread-Index: AQHSA77PVAJjCR4wUEWbyBdYh5W6AaBjd7iw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598B62B17@NJFPSRVEXG0.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: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D4598B62B17NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Virtual Interim Meeting Poll X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:50:33 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62B17NJFPSRVEXG0re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jason, Will this be a 1 hour meeting? sorry, but it makes a difference, Al From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Weil, Jason A Sent: Wednesday, August 31, 2016 3:35 PM To: lmap@ietf.org Subject: [lmap] Virtual Interim Meeting Poll LMAP Participants, Please take a few minutes to fill out the poll at the link provided for a p= otential virtual meeting before IETF 97. If there are a number of West Coas= t USA participants interested in attending let me know and I will add an 11= 00EST option. http://doodle.com/poll/hw8shm3g4h42s7gy Thanks, Jason From: lmap > on behalf = of Dan Romascanu > Date: Wednesday, August 31, 2016 at 9:49 AM To: "lmap@ietf.org" > Subject: [lmap] wg status and way ahead Resent-From: Jason Weil > Hi, We (the chairs) had a conference call with our AD (Alissa) today to discuss= WG status and next steps. Here are the main points. - in Berlin we agreed to submit revised versions of the information model a= nd data model I-Ds and send them to a second WGLC. The IM I-D was submitted= . Juergen, can you update the WG on the status of the DM model? - 2nd WGLC - to be run in September. - we shall plan for a virtual interim - target dates 10/5, 10/6, 10/7, or 1= 0/10. You shall see soon a doodle poll from Jason; if unnecessary we shall = cancel - we shall plan for a 90 min meeting at IETF 97; if unnecessary we shall ca= ncel - we want to have the documents reviewed by a broader constituency; please = use your contacts to send them to review to operators in the different comm= unities (e.g. cable access industry) or regulators. we shall also request a= n early OPS-DIR review Please answer and comment on this plan. Regards, Jason and Dan --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62B17NJFPSRVEXG0re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jason,=

Will this be a 1 hour meeting?

 

sorry, b= ut it makes a difference,

Al

 

From: lmap [mailto:lmap-bounces@ietf.org] On Beh= alf Of Weil, Jason A
Sent: Wednesday, August 31, 2016 3:35 PM=
To: lmap@ietf.org
Subject: [lmap] Virtual Interim Meet= ing Poll

 <= /o:p>

LMAP Participants,

 

Please take a few minutes to fill out the p= oll at the link provided for a potential virtual meeting before IETF 97. If= there are a number of West Coast USA participants interested in attending = let me know and I will add an 1100EST option.

 

&= nbsp;

Thanks,

Jason

 

From: lmap <lmap-bounces@ietf.org> on behalf o= f Dan Romascanu <dromasca@gmail.co= m>
Date: Wednesday, August 31, 2016 at 9:49 AM
To: <= /b>"lmap@ietf.org" <lmap@ietf.org>
Subject: [lmap]= wg status and way ahead
Resent-From: Jason Weil <jason.weil@twcable.com>

 

Hi,

We (the chairs) = had a conference call with our AD (Alissa) today to discuss WG status and n= ext steps. Here are the main points.

- in Berlin we agreed to submit revised versions of the i= nformation model and data model I-Ds and send them to a second WGLC. The IM= I-D was submitted. Juergen, can you update the WG on the status of the DM = model?

- 2nd WGLC - t= o be run in September. 

- we shall plan for a virtual interim - target dates 10/5, 10/6, 10= /7, or 10/10. You shall see soon a doodle poll from Jason; if unnecessary w= e shall cancel

- we s= hall plan for a 90 min meeting at IETF 97; if unnecessary we shall cancel

- we want to have the documents reviewed by a broader constituency;= please use your contacts to send them to review to operators in the differ= ent communities (e.g. cable access industry) or regulators. we shall also r= equest an early OPS-DIR review

Please answer and comment on this p= lan.

Regards,

Jason and Dan

= --_000_4AF73AA205019A4C8A1DDD32C034631D4598B62B17NJFPSRVEXG0re_--