From nobody Thu Jul 2 02:40:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61391B312F for ; Thu, 2 Jul 2015 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx0SrBv09z8V for ; Thu, 2 Jul 2015 02:40: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 4BA451B3136 for ; Thu, 2 Jul 2015 02:40:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4504193F; Thu, 2 Jul 2015 11:40:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mJdalKiaiPio; Thu, 2 Jul 2015 11:40:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 11:40:43 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85FFE2002B; Thu, 2 Jul 2015 11:40:45 +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 jd4NCxwo8JUv; Thu, 2 Jul 2015 11:41: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 BA44820031; Thu, 2 Jul 2015 11:40:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D8BF134E855C; Thu, 2 Jul 2015 11:40:42 +0200 (CEST) Date: Thu, 2 Jul 2015 11:40:42 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150702094042.GA11507@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2618B6@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77BA2618B6@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Definition of result values X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 09:40:49 -0000 On Tue, May 12, 2015 at 01:35:37PM +0000, Carey, Timothy (Timothy) wrote: > Team, > > I was reviewing draft-ietf-lmap-information-model-05 and had a comment regarding the ma-report-row-object. > > The definition of the result values should include how it relates to the column labels. > I would suggest something like: > A possibly empty set of result values. When present contains an ordered set of values that align to the set of column labels for the report. > Ack. I will add this to -06. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 03:09:57 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3387C1B315C for ; Thu, 2 Jul 2015 03:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVLjJpT-5ekM for ; Thu, 2 Jul 2015 03:09:54 -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 2F4F11B3160 for ; Thu, 2 Jul 2015 03:09:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8661119FF; Thu, 2 Jul 2015 12:09:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Y3vUqgGTRdNT; Thu, 2 Jul 2015 12:09:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 12:09:49 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12CDC2002B; Thu, 2 Jul 2015 12:09:52 +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 ZQ1R-zqu1K0Q; Thu, 2 Jul 2015 12:09:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6ED120013; Thu, 2 Jul 2015 12:09:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0A9D34E8689; Thu, 2 Jul 2015 12:09:49 +0200 (CEST) Date: Thu, 2 Jul 2015 12:09:49 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150702100949.GB11507@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2618CA@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77BA2618CA@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Redefining Scheduled Tasks into Scheduled Actions? X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 10:09:56 -0000 On Tue, May 12, 2015 at 01:42:55PM +0000, Carey, Timothy (Timothy) wrote: > Team, > > I was reviewing draft-ietf-lmap-information-model-05 and I didn't understand why we would redefine scheduled task to mean a scheduled action. The text of the draft talks about scheduled tasks while the model now names them scheduled actions. This seems to be confusing to me. > > We have always talked about tasks, schedules and scheduled tasks. > > Was this simply because we needed an identifier for the scheduled task? If so why wouldn't we have just added a parameter called scheduled-task-name? > We found it clearer and more concise in the YANG data model to use the terms 'task' and 'action' instead of 'task' and 'scheduled task' since 'task' and 'action' are clearly distinguishable (and they are both short). I agree that the text should be updated to be consistent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 03:45:35 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916AB1B3181 for ; Thu, 2 Jul 2015 03:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDV9JLaAqhPD for ; Thu, 2 Jul 2015 03:45:32 -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 1E6AC1B317F for ; Thu, 2 Jul 2015 03:45:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5F0DF10E1; Thu, 2 Jul 2015 12:45:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g-HLiUU8D7vc; Thu, 2 Jul 2015 12:45:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 12:45:27 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA64D20031; Thu, 2 Jul 2015 12:45:29 +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 yEeTf9BuC4sJ; Thu, 2 Jul 2015 12:45:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 780EB2002B; Thu, 2 Jul 2015 12:45:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE8AE34E8836; Thu, 2 Jul 2015 12:45:26 +0200 (CEST) Date: Thu, 2 Jul 2015 12:45:26 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20150702104526.GA184@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "lmap@ietf.org" References: <20150416193353.GA6290@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D020F956C8B@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D020F956C8B@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 10:45:33 -0000 Al, [...] > OTOH, if we can somehow combine tasks to share resources > already, then there would likely be multiple outputs, > and I support your proposal. It seems you are saying that a task can implement multiple metrics identified in the registry. The information model right now does not allow this since an ma-task-obj only has one URI that can reference the registry. I think it makes sense to change this such that a task can refer to multiple registry entries. I will do this change in the next revision of the information model unless someone speaks up against it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 05:17:15 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5544C1A040B for ; Thu, 2 Jul 2015 05:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osbwOxvtZYzT for ; Thu, 2 Jul 2015 05:17:13 -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 E5D671A03B3 for ; Thu, 2 Jul 2015 05:17:12 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id B4CC512110D; Thu, 2 Jul 2015 08:39:24 -0400 (EDT) Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.99]) by mail-azure.research.att.com (Postfix) with ESMTP id 83F26E036F; Thu, 2 Jul 2015 08:17:09 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by njmtcas1.research.att.com ([fe80::f1f7:6c06:d0d0:d48c%10]) with mapi; Thu, 2 Jul 2015 08:17:09 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Thu, 2 Jul 2015 08:17:08 -0400 Thread-Topic: [lmap] proposed information model / data model changes Thread-Index: AdC0tD7n+mumPeSfRp6c7jaVUOjbGAAC8O5w Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0662C6E621@NJFPSRVEXG0.research.att.com> References: <20150416193353.GA6290@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D020F956C8B@NJFPSRVEXG0.research.att.com> <20150702104526.GA184@elstar.local> In-Reply-To: <20150702104526.GA184@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] proposed information model / data model changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 12:17:14 -0000 Hi Juergen, You've understood my intent, thanks! The last thing we want in active measurement would be=20 to use two tasks and two independent streams of packets *just* to measure two metrics (loss ratio and delay, for example). Consolidation/computation of the metrics on a single stream=20 (where that makes sense) is essential. I think this means we can go ahead with the single metric per URI =3D> registry entry design. This is one of our recent clarifications in the TWAMP YANG model, too. best regards, Al > -----Original Message----- > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, July 02, 2015 6:45 AM > To: MORTON, ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] proposed information model / data model changes >=20 > Al, >=20 > [...] >=20 > > OTOH, if we can somehow combine tasks to share resources already, then > > there would likely be multiple outputs, and I support your proposal. >=20 > It seems you are saying that a task can implement multiple metrics > identified in the registry. The information model right now does not > allow this since an ma-task-obj only has one URI that can reference the > registry. I think it makes sense to change this such that a task can > refer to multiple registry entries. I will do this change in the next > revision of the information model unless someone speaks up against it. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Jul 2 13:31:25 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76C61A9121 for ; Thu, 2 Jul 2015 13:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQy5yFDBHddU for ; Thu, 2 Jul 2015 13:31:22 -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 553C71A910A for ; Thu, 2 Jul 2015 13:31:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 105D7F6C; Thu, 2 Jul 2015 22:31:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bqykin3pyiCG; Thu, 2 Jul 2015 22:31:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 22:31:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 710992002B; Thu, 2 Jul 2015 22:31:19 +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 HGrYpvJjzKhp; Thu, 2 Jul 2015 22:31: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 CF0D420013; Thu, 2 Jul 2015 22:31:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E615C34EB603; Thu, 2 Jul 2015 22:31:16 +0200 (CEST) Date: Thu, 2 Jul 2015 22:31:16 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150702203116.GA5561@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 20:31:24 -0000 Tim, I am not exactly sure what you are missing. In -04 we had this: object { string ma-task-name; string ma-task-role; uri ma-task-registry; datetime ma-task-last-invocation; datetime ma-task-last-successful; string ma-task-last-successful-message; datetime ma-task-last-failed; string ma-task-last-failed-message; [ma-condition-obj ma-task-conditions<0..*>]; } ma-task-status-obj object { int ma-condition-code; string ma-condition-text; } ma-condition-obj It was unclear what this means. What are the N ma-condition-objs associated to a task representing? So we clarified it by reporting the status code together with the last completion and the last failed completion. Hence we now have this: object { string ma-task-name; uri ma-task-registry-entries<1..*>; [string ma-task-role<0..*>;] datetime ma-task-last-invocation; datetime ma-task-last-completion; ==> int ma-task-last-status; string ma-task-last-message; datetime ma-task-last-failed-completion; ==> int ma-task-last-failed-status; string ma-task-last-failed-message; } ma-task-status-obj; We also had M ma-condition-objs associated with the MA itself. object { uuid ma-agent-id; urn ma-device-id; string ma-hardware; string ma-firmware; string ma-version; ma-interface-obj ma-interfaces<0..*>; ma-task-capability-obj ma-supported-tasks<0..*>; datetime ma-last-started; [ma-condition-obj ma-conditions<0..*>;] [ma-task-status-obj ma-task-status<0..*>;] } ma-status-obj; Again, it is unclear what these would be and report. So we removed them and now we have this instead: object { uuid ma-agent-id; uri ma-device-id; string ma-hardware; string ma-firmware; string ma-version; ma-interface-obj ma-interfaces<0..*>; datetime ma-last-started; [ma-task-status-obj ma-task-status<0..*>;] } ma-status-obj; Does this explanation make sense? If not, can you explain what you thought the previous definitions would contain? /js On Fri, May 15, 2015 at 12:07:25PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > Any idea on why the task capabilities and conditions were removed from the MA status in the information model? > > Thanks, > Tim > > From: Carey, Timothy (Timothy) > Sent: Monday, May 11, 2015 2:33 PM > To: lmap@ietf.org > Subject: draft-ietf-lmap-information-model-05: MA task capabilities > > Team, > > I was reviewing draft-ietf-lmap-information-model-05 and had a question on the what happened to the task capabilities and conditions as part of the MA status. The text is still in the draft but the elements are gone... > > Any help would be appreciated > > Thanks, > Tim > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 14:40:43 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D091A893E for ; Thu, 2 Jul 2015 14:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6mHrCsOw3IV for ; Thu, 2 Jul 2015 14:40:31 -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 1685D1A888B for ; Thu, 2 Jul 2015 14:40:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 11403F6C; Thu, 2 Jul 2015 23:40:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fJDwrawoFNSG; Thu, 2 Jul 2015 23:40:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 23:40:23 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1423F2002C; Thu, 2 Jul 2015 23:40:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oL1j6EFzUSiZ; Thu, 2 Jul 2015 23:40:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA40920013; Thu, 2 Jul 2015 23:40:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A130334EB6D4; Thu, 2 Jul 2015 23:40:20 +0200 (CEST) Date: Thu, 2 Jul 2015 23:40:19 +0200 From: Juergen Schoenwaelder To: "Weil, Jason" Message-ID: <20150702214018.GA5740@elstar.local> Mail-Followup-To: "Weil, Jason" , "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2612C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512100724.GC26662@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA2616F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512124209.GC41964@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA261858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512142006.GB57299@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA2626E6@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77BA262F9B@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:40:35 -0000 Hi, it seems we should separate two aspects here: 1) What exactly is the reaction to connectivity loss? The document currently says this: ma-controller-timeout: A timer is started after each successful contact with a controller. When the timer reaches the controller-timeout (measured in seconds), all schedules will be disabled, i.e., no new actions will be executed (and hence no new tasks started). The disabled schedules will be reenabled automatically once contact with a controller has been established successfully again. Note that this will not affect the execution of actions that are essential to establish contact with the controller or that perform critical housekeeping functions. An alternative that have been mentioned was to trigger suppression by a timeout. This gives more fine grained control but then there is only a single suppression object (which may be sufficient - or not). What we have now simply says that after reaching the timeout, the MA stops all measurements and this is really a safety mechanism to prevent disconnected probes to measure forever - consider the case of a company operating a controller for thousands of devices going out of business - you want the homeless MAs to stop at some point in time. For such a safety mechanism, I personally think what we have is sufficient. 2) Status reporting: Right now we have status information for tasks but none for schedules or actions. In fact, if multiple actions refer to the same task and one action provides options that make the task fail, you will be able to see the last fails but not how this links back to actions and schedules. I think this needs to be improved. As suggested, we should report the operational status of the schedules and I think we should report the status of actions instead of the status of configured tasks so that all information needed is available to understand what exactly fails. Bottom line: I think the handling of the controller timeout is good enough but the status reporting should be improved. /js On Wed, May 13, 2015 at 05:19:45PM -0400, Weil, Jason wrote: > Thanks for the reminder Tim. The one-way arrow in the framework doc > confirms it. OK so the Logging objects cover any Failure cases such as an > MA re-booting or loss of connection to the controller and status of > scheduled tasks. So what is being disabled is the Instruction set > communicated by the Controller or some subset of it. > > The MA will report its status through logging attributes when it > re-establishes communication with the controller. But yes I do agree that > the MA seems to need attributes to communicate at least enough information > to the controller about its status in order for the controller to know if > it needs to send a new or updated Instruction set. > > Jason > > On 5/13/15, 4:21 PM, "Carey, Timothy (Timothy)" > wrote: > > >Jason, > > > >Suppression is an administrative action taken through an instruction by > >the controller. Loss of connectivity (disable schedule or task) is an > >autonomous operational action taken by the MA. The problem is reporting > >and recovery - How does a management system know, in order to > >troubleshoot or remediate the event, if the schedule or task (along with > >the resulting scheduled actions) have been disabled due to an > >administrative action like suppression or via an autonomous action like > >loss of connectivity. > > > >If we would choose to treat the result of the loss of connectivity as an > >autonomous suppression event - I am fine with that but we need the MA to > >be able to report that the task, schedule and resulting scheduled actions > >are autonomously suppressed (what I called disabled). Likewise we should > >report that the MA is degraded because it currently is being autonomously > >or administratively suppressed. The MA will at least need to reevaluate > >its conditions once one clears to figure out its new status. > > > >Come to think of it - can a system other than the controller have access > >to the LMAP status information? > > Won’t the only source of the logging information bet the last controller > configured on the MA? > > >I guess this all mute if the only system allowed access to the status > >information is the controller that the MA can't access with Loss of > >connectivity. In TR-069 this is possible since the controller can be > >different from the ACS and we can have other systems that can access the > >data. I'm guessing NETConf/RESTConf allows the same. > > > >BR, > >Tim > >-----Original Message----- > >From: Weil, Jason [mailto:jason.weil@twcable.com] > >Sent: Wednesday, May 13, 2015 2:54 PM > >To: Carey, Timothy (Timothy); Juergen Schoenwaelder > >Cc: lmap@ietf.org > >Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller > >timeout > > > >I am not exactly clear what the difference is between disabled and > >suppressed tasks or schedules. It would seem that suppression is a good > >fit for the case of loss of connectivity from the way it is described in > >the information model when the the ma-controller-lost-timeout counter > >expires. Given this following note in 3.3 ("Note that Suppression has no > >effect on either Controller Tasks or Controller Schedules.²) it would > >clearly not impact future attempts to re-establish connectivity to the > >Controller and start testing where it left off. This may also benefit an > >operator by offering finer control over which tests should be suppressed > >and which shouldn¹t in the event of loss of connectivity to the > >controller. For example if may be of benefit for troubleshooting an issue > >to have a certain subset of tests continue running and collecting data > >even when connectivity to the controller is not available. > > > >Jason > > > >On 5/13/15, 8:37 AM, "Carey, Timothy (Timothy)" > > wrote: > > > >>Juergen, > >> > >>If you do not want to disable the scheduled tasks - I would actually > >>say the Parent tasks not the schedules are disabled. The reason is > >>because we are talking about wanted to disable Tasks that are not > >>related to the communication between the MA and Controller or proper > >>functioning of the MA. The MA knows this as part of their > >>TaskCapability reporting (which somehow got deleted in draft 05). > >> > >>As to the reporting of the status I would do the following: > >>Add an OperationalStatus attribute with the following values to the > >>action object (which was scheduled task): enabled, disabled-schedule, > >>disabled-task, disabled-other. > >> > >> > >> > >>I would also add an OperationalStatus to: > >>1) Schedule object with the following values: enabled, > >>disabled-suppressed, disabled-other. > >>2) Task object (I guess it could go in Task Status) with the following > >>values: enabled, disabled-suppressed, disabled-ma, disabled-other. > >>3) Measurement Agent object with the following values: enabled, > >>degraded-controller-communication, degraded-other, disabled. > >> > >>We would always include a disabled-other to allow other conditions. For > >>example in TR-069 we have the capability to administratively > >>enable/disable the multi-instance objects by conventions - so if for > >>some reason these were administratively disabled - we would set the > >>OperationalStatus to disabled-other or just disabled for the MA. > >> > >>These status' would provide a clear operational status of the elements > >>that can be disabled or degraded based on what is currently documented > >>in the framework and information model. I would suspect as we implement > >>protocols there might be other values we want to support - e.g., > >>problems with the collector-MA communication... > >> > >>BR, > >>Tim > >>-----Original Message----- > >>From: Juergen Schoenwaelder > >>[mailto:j.schoenwaelder@jacobs-university.de] > >>Sent: Tuesday, May 12, 2015 9:20 AM > >>To: Carey, Timothy (Timothy) > >>Cc: lmap@ietf.org > >>Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller > >>timeout > >> > >>On Tue, May 12, 2015 at 01:04:49PM +0000, Carey, Timothy (Timothy) wrote: > >> > >>> So does that now mean we need to have a operational status now for a > >>> scheduled task? I can see it now as attribute with values like: > >>> enabled, disabled, suppressed and errored or possibly a conditions > >>> object? > >> > >>I think there two questions here: > >> > >>a) If I loose connectivity, do I disable all schedules (and thus > >> implicitely all actions) or do I disable scheduled tasks? My idea > >> was to simply disable all schedules (and as such the schedules have > >> their state changed to disabled). > >> > >> The suppression mechanism can suppress both a list of tasks and a > >> list of schedules and it is configurable what is being suppressed. > >> > >> One option is that loss of connectivity simply causes suppression > >> to be activated. Another option is that loss of connectivity > >> supresses all tasks that are not essential for communication with a > >> controller and house keeping. Another option is that loss of > >> connectivity suppresses all schedules. We need to select one. > >> > >>b) Do we expose the internal state that is maintained? Right now, we > >> do not expose any operational state for schedules. But we do expose > >> operational state for tasks. If loss of connectivity means we > >> disable all tasks that are not essential for communication with a > >> controller and house keeping, than exposing that information would > >> be a rather minor change to the information and data model. > >> > >> A task state would then be enabled (default), suppressed or > >> disabled. Error information is already covered in the last-failed > >> attributes of a task. (And this is useful in situations where tasks > >> fail occasionally so you can get information about the last failure > >> even though the task is working fine right now). > >> > >>/js > >> > >>-- > >>Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>Fax: +49 421 200 3103 > >> > >>_______________________________________________ > >>lmap mailing list > >>lmap@ietf.org > >>https://www.ietf.org/mailman/listinfo/lmap > > > > > >This E-mail and any of its attachments may contain Time Warner Cable > >proprietary information, which is privileged, confidential, or subject to > >copyright belonging to Time Warner Cable. This E-mail is intended solely > >for the use of the individual or entity to which it is addressed. If you > >are not the intended recipient of this E-mail, you are hereby notified > >that any dissemination, distribution, copying, or action taken in > >relation to the contents of and attachments to this E-mail is strictly > >prohibited and may be unlawful. If you have received this E-mail in > >error, please notify the sender immediately and permanently delete the > >original and any copy of this E-mail and any printout. > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -- 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 Jul 3 11:55:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AC21A1EFE; Fri, 3 Jul 2015 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj_4LPTNWbgD; Fri, 3 Jul 2015 11:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A7B1A1C00; Fri, 3 Jul 2015 11:55:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150703185543.14550.81834.idtracker@ietfa.amsl.com> Date: Fri, 03 Jul 2015 11:55:43 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-06.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 18:55:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-06.txt Pages : 39 Date : 2015-07-03 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the MA or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the MA that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 3 12:02:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4A51A1DBE; Fri, 3 Jul 2015 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZMvafhCtQAL; Fri, 3 Jul 2015 12:01:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EAD1A6EED; Fri, 3 Jul 2015 12:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150703190122.10352.10916.idtracker@ietfa.amsl.com> Date: Fri, 03 Jul 2015 12:01:22 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-01.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 19:01:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-01.txt Pages : 38 Date : 2015-07-03 Abstract: This document defines a data model for Large-Scale Measurement Platforms (LMAP). The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 4 08:40:41 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08C1A1F70; Sat, 4 Jul 2015 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veq-AUo6I5Iu; Sat, 4 Jul 2015 08:40:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 321EB1A1A98; Sat, 4 Jul 2015 08:40:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150704154037.25948.97012.idtracker@ietfa.amsl.com> Date: Sat, 04 Jul 2015 08:40:37 -0700 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-restconf-00.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 15:40:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance Working Group of the IETF. Title : Using RESTCONF with LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-restconf-00.txt Pages : 10 Date : 2015-07-03 Abstract: This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-restconf-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 02:26:36 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E761A9237 for ; Mon, 6 Jul 2015 02:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqiBiJ_33T55 for ; Mon, 6 Jul 2015 02:26:33 -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 B90CB1A9240 for ; Mon, 6 Jul 2015 02:26:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 92C928EC for ; Mon, 6 Jul 2015 11:26:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HZ40MyLHj_xQ for ; Mon, 6 Jul 2015 11:26:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 6 Jul 2015 11:26:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D62DC2002C for ; Mon, 6 Jul 2015 11:26:20 +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 jzgqv79S5h4G for ; Mon, 6 Jul 2015 11:26:16 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A9F2420013 for ; Mon, 6 Jul 2015 11:26:19 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 11:26:19 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: [review]: draft-ietf-lmap-restconf-00 Thread-Index: AQHQt83Q7NE+WQc/pkm/Z0ymeHchkQ== Date: Mon, 6 Jul 2015 09:26:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_03C1DB1C-6B38-421B-B1F8-63A9CE91C941"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "Bajpai, Vaibhav" Subject: [lmap] [review]: draft-ietf-lmap-restconf-00 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:26:35 -0000 --Apple-Mail=_03C1DB1C-6B38-421B-B1F8-63A9CE91C941 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, > Title : Using RESTCONF with LMAP Measurement Agents > Authors : Juergen Schoenwaelder > Vaibhav Bajpai > Filename : draft-ietf-lmap-RESTCONF-00.txt > Pages : 10 > Date : 2015-07-03 I made some notes. Thought to share it along: a) The LMAP framework document reference is outdated: The draft currently cites -12 (while the latest version is -14). = Although the framework may become an RFC by the next revision. b) Appendix A: Response to Protocol Comparison Criteria: Perhaps we promote the example exchanges (Appendix B and Appendix C) = ahead of the response to protocol selection critera? -- or maybe we can just = remove it given the document is a WG document now. The response is documented = already in the non-WG version of this document. Currently it digresses the reader = into a tangent. c) Examples: (Appendix B and C): Perhaps we reiterate that in the example exchanges; the MA is the = RESTCONF server and the LMAP controller/collectors are the RESTCONF clients. = Although it's clear that a client would be sending GET/POST requests; but maybe = adding this line avoids any confusion, given that there is also a call-home = mechanism that switches roles in the very beginning where the MA works as a TCP = client. d) Appendix C > The first step taken by the collector is to lookup the event = stream resource. >=20 > C: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ > C: /streams/stream=3DNETCONF/encoding=3Djson/events HTTP/1.1 > C: Host: example.com > C: Accept: application/yang.data+xml Perhaps we should add (as previously indicated in Appendix B) that = prefix C: indicates the LMAP collector. > C: GET /streams/NETCONF-json HTTP/1.1 > C: Host: example.com > C: Accept: text/event-stream > C: Cache-Control: no-cache > C: Connection: keep-alive >=20 > M: data: { > M: data: "ietf-restconf:notification": { > M: data: "event-time": "2015-03-25T00:01:00+00:00", > M: data: "ietf-lmap:report": { > M: data: "date": "2015-03-25T00:01:00+00:00", > M: data: "agent-id": "xxx", > M: data: "header": { > M: data: "column": "target", > M: data: "column": "rtt" > M: data: } > M: data: "row": { > M: data: "start": "2015-03-25T00:00:55+00:00", > M: data: "value": "192.0.2.1", > M: data: "value": 42 > M: data: } > M: data: "row": { > M: data: "start": "2015-03-25T00:00:56+00:00", > M: data: "value": "192.0.2.2", > M: data: "value": 24 > M: data: } > M: data: } > M: data: } > M: data: } Perhaps we add a line to indicate that this response is asynchronous and = not an immediate reaction to the LMAP controller's GET request? e) Typos/Edits > levels of granularity using DELETE, PATCH, POST, and PUT methods. - using HTTP DELETE, ... methods > One way of mapping the information model parts relevant for = reports > into a YANG data model is the usage of YANG notifications. - isn't it RESTCONF notifications? -- or YANG-defined notifications? > Note that alternative designs are possible. - alternative designs are also possible. > One option is to make the collector a RESTCONF server and to have = the MA > push results to the collector by posting to resources on the = controller. - by posting to resources on the =E2=80=98collector=E2=80=99? (instead = of controller) > Below is an XML representation of instance data conforming to the > YANG data model is shown below. An XML representation of instance data conforming to the YANG data model = is shown below. > Note that some of the strings are references to other portions of = the > instance data not show here. This is again taken from = [I-D.ietf-lmap-yang]. Note that some of the strings which are references to other portions of = the instance data are not shown here. f) Generally, do you think we should prepend LMAP every time we use the = controller and collector, or should it be obvious given that this is an LMAP = document? Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --Apple-Mail=_03C1DB1C-6B38-421B-B1F8-63A9CE91C941 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVmkm7AAoJEHR3XKwTWKOZ01AIAJeRjsjDPxdNquVpyOUsXgMD sRKtjl3IauxQNlYil8xxyd/nUV7DFaa9PM6XgfiqRWY/jbbt1EHSz1SnKqn1elZL cRrARRx4qr8f0bRqwx02G9B+zU0ZHVQ3jSx9ZlbFRARzuQIyV70zNtyqbXjQ7842 Wz5GB8Z5JuvTTCOyUvwxR2AmgIY/nue1Xx9hl3JwwFGGXzdVUh3MQU8SLlKZmYYd b0wgSs9g1IsIgMFdyoVQrtPJSATZwwkapIw6t7HOap/MbOXln9Dy1kpzsdfU3KDu w2ynCpHlqotjKMUJf/VcBkFZWCbipwPkGTfK8u1W7tWkLsGLMyD/LUOBR0k3T54= =yTPs -----END PGP SIGNATURE----- --Apple-Mail=_03C1DB1C-6B38-421B-B1F8-63A9CE91C941-- From nobody Mon Jul 6 03:08:44 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0374C1ACCE1 for ; Mon, 6 Jul 2015 03:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUP2opOE9xU1 for ; Mon, 6 Jul 2015 03:08:40 -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 311AC1AC432 for ; Mon, 6 Jul 2015 03:08:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8852772F for ; Mon, 6 Jul 2015 12:08:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kTjVWDz2k5xe for ; Mon, 6 Jul 2015 12:08:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 6 Jul 2015 12:08:37 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D6B22002B for ; Mon, 6 Jul 2015 12:08:37 +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 u8nau6iexMsG for ; Mon, 6 Jul 2015 12:08:58 +0200 (CEST) Received: from exchange.jacobs-university.de (shubcas02.jacobs.jacobs-university.de [10.70.0.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id F0BF92002C for ; Mon, 6 Jul 2015 12:08:36 +0200 (CEST) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS02.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 12:08:36 +0200 From: "Bajpai, Vaibhav" To: "" Thread-Topic: [review]: draft-ietf-lmap-yang-01 Thread-Index: AQHQt9O4gyOc3IgODkiP2EY4IebDhQ== Date: Mon, 6 Jul 2015 10:08:35 +0000 Message-ID: <488631DB-7776-4A87-971E-91E752A77B86@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_70CA5A62-C45C-4ED6-88FC-77F8C65D9839"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "Bajpai, Vaibhav" Subject: [lmap] [review]: draft-ietf-lmap-yang-01 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 10:08:43 -0000 --Apple-Mail=_70CA5A62-C45C-4ED6-88FC-77F8C65D9839 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, > Title : A YANG Data Model for LMAP Measurement Agents > Authors : Juergen Schoenwaelder > Vaibhav Bajpai > Filename : draft-ietf-lmap-yang-01.txt > Pages : 38 > Date : 2015-07-03 I made some notes. Thought to share it along. a) The LMAP framework document reference is outdated: The draft currently cites -12 (while the latest version is -14). = Although the framework may become an RFC soon. b) Periodic events with milliseconds interval granularity At some point, we were discussing on the mailing list whether a periodic = event with a milliseconds interval granularity is needed? -- would a seconds interval granularity suffice? c) Typos/Edits > A schedule of receiving the output produced by this action. A schedule receiving the output produced by this action. > execution mode of this schedule determins determins -> determines > LMAP agent (multiple occurrences) LMAP measurement agent > Options may be used to identify the role of a task or to pass a = channel > name to a task. Options may also be used ... > * Common Information Objects: Configuration Configuration is not a common information object. > Schedules control with tasks are executed by the LMAP = implementation. Schedules control which tasks ... > The locally-unique, administratively assigned name for > this scheduled task. ... name for this schedule. Best, Vaibhav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --Apple-Mail=_70CA5A62-C45C-4ED6-88FC-77F8C65D9839 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVmlOjAAoJEHR3XKwTWKOZLxUH/3l3TDdqna7yndhHcUKa12ez x5w2LVQZEZptiRhxXMcqoomX+LRLGM6QzPNBeQY8VBIN97otA5EE7m+tsfPlQLeV uIySKInd34/HUE0W/nIPod3iwDrIkOYrwrDlulra7k0+a8RUJhwCkbQhxfYIH29d n5FfYS7RASAl2HAkd3oUD64ZQFUqABwEboA7hIw8Z46Hg4OrYNeU93ZsoDskwOm5 1ovP1ISMgYkpQGJi/XhTiGUd/gvtX4PZpfSV7ag7nYuo/hVPO/TpcR5rDSwoRBuw /m472D+7JkqI1P2VbTvSX8OBv/I5NSUhU0RJYn+qOUHOGMM5kb3frzLqmZJFXO8= =RMkW -----END PGP SIGNATURE----- --Apple-Mail=_70CA5A62-C45C-4ED6-88FC-77F8C65D9839-- From nobody Mon Jul 6 04:40:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0911A0006 for ; Mon, 6 Jul 2015 04:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.998 X-Spam-Level: * X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IObiLzsQubST for ; Mon, 6 Jul 2015 04:40:27 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.231.228]) by ietfa.amsl.com (Postfix) with ESMTP id 923161A0396 for ; Mon, 6 Jul 2015 04:39:40 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7A8654E9FD; Mon, 6 Jul 2015 20:39:39 +0900 (JST) Received: from NW60676BAA5D7F6.local (unknown [IPv6:2402:c800:ff06:0:1463:9fc2:b470:3502]) by z.nttv6.jp (NTTv6MTA) with ESMTPSA id 6FE453AC83; Mon, 6 Jul 2015 20:39:39 +0900 (JST) Message-ID: <559A68FB.1020302@nttv6.jp> Date: Mon, 06 Jul 2015 20:39:39 +0900 From: Motoyuki Ooki User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: lmap@ietf.org Content-Type: multipart/alternative; boundary="------------060509040600000605030308" Archived-At: Cc: dromasca@avaya.com, jason.weil@twcable.com Subject: [lmap] draft-ooki-lmap-internet-measurement-system X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:40:30 -0000 This is a multi-part message in MIME format. --------------060509040600000605030308 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Dear all, (CC : Dear LMAP chairs) I'm Motoyuki Ooki from NTT Communications in Japan. We are developing our original measurement system for end-to-end performance. I updated our draft (ver. 02) a few weeks ago. https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement-system/ This document describes an experience of Japanese Internet measurement system to measure end-to-end performance of user's experience. This document is expected to be useful for selecting the next chartered items in LMAP WG. If you have a time, please look through it, and all kind of feedback are welcome. Best regards, Motoyuki Ooki --------------060509040600000605030308 Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Dear all,
(CC : Dear LMAP chairs)

I'm Motoyuki Ooki from NTT Communications in Japan.
We are developing our original measurement system for end-to-end performance.
I updated our draft (ver. 02) a few weeks ago.
https://datatracker.ietf.org/doc/draft-ooki-lmap-internet-measurement-system/

This document describes an experience of Japanese Internet measurement system to measure end-to-end performance of user's experience.
This document is expected to be useful for selecting the next chartered items in LMAP WG.

If you have a time, please look through it, and all kind of feedback are welcome.

Best regards,
Motoyuki Ooki --------------060509040600000605030308-- From nobody Mon Jul 6 05:15:44 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9C1ACE4D for ; Mon, 6 Jul 2015 05:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2upGgLUEAu2J for ; Mon, 6 Jul 2015 05:15:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4235B1ACE98 for ; Mon, 6 Jul 2015 05:15:34 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 055C5FEDE0794; Mon, 6 Jul 2015 12:15:28 +0000 (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 t66CFTUh001822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 12:15:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 08:15:29 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities Thread-Index: AQHQtQYblerhvmmR+Emt5rEWmPZzVZ3OXP0g Date: Mon, 6 Jul 2015 12:15:29 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC20B29A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150702203116.GA5561@elstar.local> In-Reply-To: <20150702203116.GA5561@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: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:15:43 -0000 Juergen, The conditions associated with the task where when this task was executed w= hat were the conditions (possibly things like WAN link down, not enough mem= ory for the task to execute, cross traffic occurred during the task) that r= esulted in the task's status. Likewise in the MA - the conditions are the conditions of the MA at the tim= e of retrieval (e.g., unable to connect to collector). At first we had certain conditions spelled out in the information model but= we moved them in "generic" implementation specific conditions. Finally the supported tasks are simply the tasks (tests) that the MA is abl= e to execute (name, role and URI of the registry). A controller will need t= o know this in order to ask a MA to execute a task. Hope that helps, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, July 02, 2015 3:31 PM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilit= ies Tim, I am not exactly sure what you are missing. In -04 we had this: object { string ma-task-name; string ma-task-role; uri ma-task-registry; datetime ma-task-last-invocation; datetime ma-task-last-successful; string ma-task-last-successful-message; datetime ma-task-last-failed; string ma-task-last-failed-message; [ma-condition-obj ma-task-conditions<0..*>]; } ma-task-status-obj object { int ma-condition-code; string ma-condition-text; } ma-condition-obj It was unclear what this means. What are the N ma-condition-objs associated= to a task representing? So we clarified it by reporting the status code to= gether with the last completion and the last failed completion. Hence we no= w have this: object { string ma-task-name; uri ma-task-registry-entries<1..*>; [string ma-task-role<0..*>;] datetime ma-task-last-invocation; datetime ma-task-last-completion; =3D=3D> int ma-task-last-status; string ma-task-last-message; datetime ma-task-last-failed-completion; =3D=3D> int ma-task-last-failed-status; string ma-task-last-failed-message; } ma-task-status-obj; We also had M ma-condition-objs associated with the MA itself. object { uuid ma-agent-id; urn ma-device-id; string ma-hardware; string ma-firmware; string ma-version; ma-interface-obj ma-interfaces<0..*>; ma-task-capability-obj ma-supported-tasks<0..*>; datetime ma-last-started; [ma-condition-obj ma-conditions<0..*>;] [ma-task-status-obj ma-task-status<0..*>;] } ma-status-obj; Again, it is unclear what these would be and report. So we removed them and= now we have this instead: object { uuid ma-agent-id; uri ma-device-id; string ma-hardware; string ma-firmware; string ma-version; ma-interface-obj ma-interfaces<0..*>; datetime ma-last-started; [ma-task-status-obj ma-task-status<0..*>;] } ma-status-obj; Does this explanation make sense? If not, can you explain what you thought = the previous definitions would contain? /js On Fri, May 15, 2015 at 12:07:25PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > Any idea on why the task capabilities and conditions were removed from th= e MA status in the information model? >=20 > Thanks, > Tim >=20 > From: Carey, Timothy (Timothy) > Sent: Monday, May 11, 2015 2:33 PM > To: lmap@ietf.org > Subject: draft-ietf-lmap-information-model-05: MA task capabilities >=20 > Team, >=20 > I was reviewing draft-ietf-lmap-information-model-05 and had a question o= n the what happened to the task capabilities and conditions as part of the = MA status. The text is still in the draft but the elements are gone... >=20 > Any help would be appreciated >=20 > Thanks, > Tim >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 6 05:29:17 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE051A1AA2 for ; Mon, 6 Jul 2015 05:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02PCVKcd7H3z for ; Mon, 6 Jul 2015 05:29:14 -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 0C4C71ACEAB for ; Mon, 6 Jul 2015 05:29:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 18D0D101C; Mon, 6 Jul 2015 14:29:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TsEk4OQ7_7Ou; Mon, 6 Jul 2015 14:29:09 +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, 6 Jul 2015 14:29:08 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B8172002C; Mon, 6 Jul 2015 14:29:09 +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 gV1WxMcjQkcl; Mon, 6 Jul 2015 14:29:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01F8C2002B; Mon, 6 Jul 2015 14:29:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6BF7534EEBC7; Mon, 6 Jul 2015 14:29:04 +0200 (CEST) Date: Mon, 6 Jul 2015 14:29:03 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150706122903.GA972@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150702203116.GA5561@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC20B29A@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC20B29A@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:29:16 -0000 On Mon, Jul 06, 2015 at 12:15:29PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > The conditions associated with the task where when this task was executed what were the conditions (possibly things like WAN link down, not enough memory for the task to execute, cross traffic occurred during the task) that resulted in the task's status. But is this not captured in ma-task-last-status / ma-task-last-message and ma-task-last-failed-status / ma-task-last-failed-message? > Likewise in the MA - the conditions are the conditions of the MA at the time of retrieval (e.g., unable to connect to collector). In the new model, would this not simply be reported as a task failure? What are the MA specific conditions? We had in another thread a proposal to have an MA status object. What else would be needed? Perhaps we are fine if we can get number of states defined that we need to distinguish. > At first we had certain conditions spelled out in the information model but we moved them in "generic" implementation specific conditions. > > Finally the supported tasks are simply the tasks (tests) that the MA is able to execute (name, role and URI of the registry). A controller will need to know this in order to ask a MA to execute a task. Yes, this makes sense. But it does not feel right to associate status codes returned by actions with the static task list that serves as an inventory - they IMHO should be associated with actions. /js > Hope that helps, > > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 02, 2015 3:31 PM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities > > Tim, > > I am not exactly sure what you are missing. In -04 we had this: > > object { > string ma-task-name; > string ma-task-role; > uri ma-task-registry; > datetime ma-task-last-invocation; > datetime ma-task-last-successful; > string ma-task-last-successful-message; > datetime ma-task-last-failed; > string ma-task-last-failed-message; > [ma-condition-obj ma-task-conditions<0..*>]; > } ma-task-status-obj > > object { > int ma-condition-code; > string ma-condition-text; > } ma-condition-obj > > It was unclear what this means. What are the N ma-condition-objs associated to a task representing? So we clarified it by reporting the status code together with the last completion and the last failed completion. Hence we now have this: > > object { > string ma-task-name; > uri ma-task-registry-entries<1..*>; > [string ma-task-role<0..*>;] > datetime ma-task-last-invocation; > datetime ma-task-last-completion; > ==> int ma-task-last-status; > string ma-task-last-message; > datetime ma-task-last-failed-completion; > ==> int ma-task-last-failed-status; > string ma-task-last-failed-message; > } ma-task-status-obj; > > We also had M ma-condition-objs associated with the MA itself. > > object { > uuid ma-agent-id; > urn ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > ma-task-capability-obj ma-supported-tasks<0..*>; > datetime ma-last-started; > [ma-condition-obj ma-conditions<0..*>;] > [ma-task-status-obj ma-task-status<0..*>;] > } ma-status-obj; > > Again, it is unclear what these would be and report. So we removed them and now we have this instead: > > object { > uuid ma-agent-id; > uri ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > datetime ma-last-started; > [ma-task-status-obj ma-task-status<0..*>;] > } ma-status-obj; > > Does this explanation make sense? If not, can you explain what you thought the previous definitions would contain? > > /js > > On Fri, May 15, 2015 at 12:07:25PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > > > > Any idea on why the task capabilities and conditions were removed from the MA status in the information model? > > > > Thanks, > > Tim > > > > From: Carey, Timothy (Timothy) > > Sent: Monday, May 11, 2015 2:33 PM > > To: lmap@ietf.org > > Subject: draft-ietf-lmap-information-model-05: MA task capabilities > > > > Team, > > > > I was reviewing draft-ietf-lmap-information-model-05 and had a question on the what happened to the task capabilities and conditions as part of the MA status. The text is still in the draft but the elements are gone... > > > > Any help would be appreciated > > > > Thanks, > > Tim > > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- 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 Jul 6 05:29:38 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8D71ACEA4 for ; Mon, 6 Jul 2015 05:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQKC8DERSbqE for ; Mon, 6 Jul 2015 05:29:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 AA05C1ACE5F for ; Mon, 6 Jul 2015 05:29:33 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 33D9CBD8A35C7; Mon, 6 Jul 2015 12:29:29 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t66CTSdC026791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 12:29:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 08:29:29 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder , "Weil, Jason" Thread-Topic: [lmap] draft-ietf-lmap-information-model-05: Controller timeout Thread-Index: AdCMHecUFUgxoWRISVOQIyTHkXEC2AAnxEkAAATNJ5AAAJpsgAAH9ouw///bqQD//tQ9MIBRirhZ//pUR1A= Date: Mon, 6 Jul 2015 12:29:28 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC20B30D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77BA2612C2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512100724.GC26662@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA2616F5@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512124209.GC41964@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA261858@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150512142006.GB57299@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77BA2626E6@US70UWXCHMBA05.zam.alcatel-lucent.com> <9966516C6EB5FC4381E05BF80AA55F77BA262F9B@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150702214018.GA5740@elstar.local> In-Reply-To: <20150702214018.GA5740@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:29:37 -0000 SnVlcmdlbiwNCg0KWWVzIHRoZXJlIGFyZSAyIGlzc3VlcyBmcm9tIG15IG5vdGVzOg0KMSkgTmVl ZCB0byBkZXNjcmliZSBpZiBzY2hlZHVsZXMsIHRhc2tzIG9yIHNjaGVkdWxlZCBhY3Rpb25zIGFy ZSB0byBiZSBkaXNhYmxlZCBhbmQgaG93IHRoZXkgYXJlIHJlLWVuYWJsZWQuDQoNCjIpIERldGVy bWluZSBob3cgdG8gZGVmaW5lIHRoZSBvcGVyYXRpb25hbCBzdGF0dXMgb2Ygc2NoZWR1bGVzLCB0 YXNrcywgc2NoZWR1bGVkIGFjdGlvbnMgYW5kIE1Bcw0KDQoNClNvIGlubGluZSA8VEFDPg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFtt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXSANClNlbnQ6IFRodXJz ZGF5LCBKdWx5IDAyLCAyMDE1IDQ6NDAgUE0NClRvOiBXZWlsLCBKYXNvbg0KQ2M6IENhcmV5LCBU aW1vdGh5IChUaW1vdGh5KTsgbG1hcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtsbWFwXSBkcmFm dC1pZXRmLWxtYXAtaW5mb3JtYXRpb24tbW9kZWwtMDU6IENvbnRyb2xsZXIgdGltZW91dA0KDQpI aSwNCg0KaXQgc2VlbXMgd2Ugc2hvdWxkIHNlcGFyYXRlIHR3byBhc3BlY3RzIGhlcmU6DQoNCjEp IFdoYXQgZXhhY3RseSBpcyB0aGUgcmVhY3Rpb24gdG8gY29ubmVjdGl2aXR5IGxvc3M/DQoNCiAg IFRoZSBkb2N1bWVudCBjdXJyZW50bHkgc2F5cyB0aGlzOg0KDQogICBtYS1jb250cm9sbGVyLXRp bWVvdXQ6ICAgIEEgdGltZXIgaXMgc3RhcnRlZCBhZnRlciBlYWNoIHN1Y2Nlc3NmdWwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgY29udGFjdCB3aXRoIGEgY29udHJvbGxlci4gIFdoZW4g dGhlIHRpbWVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWNoZXMgdGhlIGNvbnRy b2xsZXItdGltZW91dCAobWVhc3VyZWQgaW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c2Vjb25kcyksIGFsbCBzY2hlZHVsZXMgd2lsbCBiZSBkaXNhYmxlZCwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaS5lLiwgbm8gbmV3IGFjdGlvbnMgd2lsbCBiZSBleGVjdXRlZCAoYW5k DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhlbmNlIG5vIG5ldyB0YXNrcyBzdGFydGVk KS4gIFRoZSBkaXNhYmxlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzY2hlZHVsZXMg d2lsbCBiZSByZWVuYWJsZWQgYXV0b21hdGljYWxseQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvbmNlIGNvbnRhY3Qgd2l0aCBhIGNvbnRyb2xsZXIgaGFzIGJlZW4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZXN0YWJsaXNoZWQgc3VjY2Vzc2Z1bGx5IGFnYWluLiAgTm90ZSB0 aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgd2lsbCBub3QgYWZmZWN0IHRo ZSBleGVjdXRpb24gb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWN0aW9ucyB0aGF0 IGFyZSBlc3NlbnRpYWwgdG8gZXN0YWJsaXNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnRhY3Qgd2l0aCB0aGUgY29udHJvbGxlciBvciB0aGF0IHBlcmZvcm0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY3JpdGljYWwgaG91c2VrZWVwaW5nIGZ1bmN0aW9ucy4NCg0KPFRB Qz4gT2sgc28gaXQgd2lsbCBiZSBTY2hlZHVsZXMgdGhhdCBhcmUgZGlzYWJsZWQgYW5kIGJ5IGFz c29jaWF0aW9uIGFueSBhY3Rpb25zIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2NoZWR1bGU/IFdlIHNo b3VsZCBzdGF0ZSB0aGF0LiAgSG93IGRvZXMgYW4gTUEga25vdyB3aGljaCB0YXNrJ3MgYXJlIGhv dXNla2VlcGluZyBhbmQgd2hpY2ggb2YgaG91c2VrZWVwaW5nIGFyZSBjcml0aWNhbCAtIGlzIHRo YXQgYSBvcHRpb24gcGFzc2VkIGJ5IHRoZSBjb250cm9sbGVyIGZvciB0aGUgdGFzaz8gV2Ugc2hv dWxkIHN0YXRlIGhvdyBjcml0aWNhbCBob3VzZWtlZXBpbmcgdGFza3MgYXJlIGlkZW50aWZpZWQu DQoNCiAgIEFuIGFsdGVybmF0aXZlIHRoYXQgaGF2ZSBiZWVuIG1lbnRpb25lZCB3YXMgdG8gdHJp Z2dlciBzdXBwcmVzc2lvbg0KICAgYnkgYSB0aW1lb3V0LiBUaGlzIGdpdmVzIG1vcmUgZmluZSBn cmFpbmVkIGNvbnRyb2wgYnV0IHRoZW4gdGhlcmUNCiAgIGlzIG9ubHkgYSBzaW5nbGUgc3VwcHJl c3Npb24gb2JqZWN0ICh3aGljaCBtYXkgYmUgc3VmZmljaWVudCAtIG9yDQogICBub3QpLg0KDQog ICBXaGF0IHdlIGhhdmUgbm93IHNpbXBseSBzYXlzIHRoYXQgYWZ0ZXIgcmVhY2hpbmcgdGhlIHRp bWVvdXQsIHRoZQ0KICAgTUEgc3RvcHMgYWxsIG1lYXN1cmVtZW50cyBhbmQgdGhpcyBpcyByZWFs bHkgYSBzYWZldHkgbWVjaGFuaXNtIHRvDQogICBwcmV2ZW50IGRpc2Nvbm5lY3RlZCBwcm9iZXMg dG8gbWVhc3VyZSBmb3JldmVyIC0gY29uc2lkZXIgdGhlIGNhc2UNCiAgIG9mIGEgY29tcGFueSBv cGVyYXRpbmcgYSBjb250cm9sbGVyIGZvciB0aG91c2FuZHMgb2YgZGV2aWNlcyBnb2luZw0KICAg b3V0IG9mIGJ1c2luZXNzIC0geW91IHdhbnQgdGhlIGhvbWVsZXNzIE1BcyB0byBzdG9wIGF0IHNv bWUgcG9pbnQNCiAgIGluIHRpbWUuIEZvciBzdWNoIGEgc2FmZXR5IG1lY2hhbmlzbSwgSSBwZXJz b25hbGx5IHRoaW5rIHdoYXQgd2UNCiAgIGhhdmUgaXMgc3VmZmljaWVudC4NCg0KPFRBQz4gSSBh bSBjZXJ0YWlubHkgZmluZSB3aXRoIGRpc2FibGluZyB0aGUgc2NoZWR1bGVzIC0ganVzdCBuZWVk IHRoZSBjbGFyaXR5IGluIHRoZSB0ZXh0IGFuZCByZXNvbHZlIHRoZSBpZGVudGlmaWNhdGlvbiBv ZiBjcml0aWNhbCBob3VzZWtlZXBpbmcgdGFza3MuIFNlZSBteSBjb21tZW50IGFib3ZlLg0KDQoy KSBTdGF0dXMgcmVwb3J0aW5nOiBSaWdodCBub3cgd2UgaGF2ZSBzdGF0dXMgaW5mb3JtYXRpb24g Zm9yIHRhc2tzDQogICBidXQgbm9uZSBmb3Igc2NoZWR1bGVzIG9yIGFjdGlvbnMuIEluIGZhY3Qs IGlmIG11bHRpcGxlIGFjdGlvbnMNCiAgIHJlZmVyIHRvIHRoZSBzYW1lIHRhc2sgYW5kIG9uZSBh Y3Rpb24gcHJvdmlkZXMgb3B0aW9ucyB0aGF0IG1ha2UNCiAgIHRoZSB0YXNrIGZhaWwsIHlvdSB3 aWxsIGJlIGFibGUgdG8gc2VlIHRoZSBsYXN0IGZhaWxzIGJ1dCBub3QgaG93DQogICB0aGlzIGxp bmtzIGJhY2sgdG8gYWN0aW9ucyBhbmQgc2NoZWR1bGVzLg0KDQogICBJIHRoaW5rIHRoaXMgbmVl ZHMgdG8gYmUgaW1wcm92ZWQuIEFzIHN1Z2dlc3RlZCwgd2Ugc2hvdWxkIHJlcG9ydA0KICAgdGhl IG9wZXJhdGlvbmFsIHN0YXR1cyBvZiB0aGUgc2NoZWR1bGVzIGFuZCBJIHRoaW5rIHdlIHNob3Vs ZA0KICAgcmVwb3J0IHRoZSBzdGF0dXMgb2YgYWN0aW9ucyBpbnN0ZWFkIG9mIHRoZSBzdGF0dXMg b2YgY29uZmlndXJlZA0KICAgdGFza3Mgc28gdGhhdCBhbGwgaW5mb3JtYXRpb24gbmVlZGVkIGlz IGF2YWlsYWJsZSB0byB1bmRlcnN0YW5kDQogICB3aGF0IGV4YWN0bHkgZmFpbHMuDQoNCjxUQUM+ IFllcyBpbiB0aGUgcGFzdCBhbiBvcGVyYXRpb25hbCBzdGF0dXMgY291bGQgYmUgZGVwZW5kZW50 IG9uIHRoZSBvcGVyYXRpb25hbCBzdGF0dXMgb2YgYSAiaGlnaGVyLW9yZGVyIiBlbnRpdHkgKGJl IGF1dG9ub21vdXNseSBvdXQgb2Ygc2VydmljZSkgLSB0aGF0IGlzIHdoYXQgSSB0aGluayB0aGUg c3RhdHVzIG9mIHRoZSBhY3Rpb24gc2hvdWxkIGJlIC0gbGlua2VkIHRvIHRoZSBzY2hlZHVsZS4N Cg0KQm90dG9tIGxpbmU6IEkgdGhpbmsgdGhlIGhhbmRsaW5nIG9mIHRoZSBjb250cm9sbGVyIHRp bWVvdXQgaXMgZ29vZCBlbm91Z2ggYnV0IHRoZSBzdGF0dXMgcmVwb3J0aW5nIHNob3VsZCBiZSBp bXByb3ZlZC4NCg0KL2pzDQoNCk9uIFdlZCwgTWF5IDEzLCAyMDE1IGF0IDA1OjE5OjQ1UE0gLTA0 MDAsIFdlaWwsIEphc29uIHdyb3RlOg0KPiBUaGFua3MgZm9yIHRoZSByZW1pbmRlciBUaW0uIFRo ZSBvbmUtd2F5IGFycm93IGluIHRoZSBmcmFtZXdvcmsgZG9jIA0KPiBjb25maXJtcyBpdC4gT0sg c28gdGhlIExvZ2dpbmcgb2JqZWN0cyBjb3ZlciBhbnkgRmFpbHVyZSBjYXNlcyBzdWNoIGFzIA0K PiBhbiBNQSByZS1ib290aW5nIG9yIGxvc3Mgb2YgY29ubmVjdGlvbiB0byB0aGUgY29udHJvbGxl ciBhbmQgc3RhdHVzIG9mIA0KPiBzY2hlZHVsZWQgdGFza3MuIFNvIHdoYXQgaXMgYmVpbmcgZGlz YWJsZWQgaXMgdGhlIEluc3RydWN0aW9uIHNldCANCj4gY29tbXVuaWNhdGVkIGJ5IHRoZSBDb250 cm9sbGVyIG9yIHNvbWUgc3Vic2V0IG9mIGl0Lg0KPiANCj4gVGhlIE1BIHdpbGwgcmVwb3J0IGl0 cyBzdGF0dXMgdGhyb3VnaCBsb2dnaW5nIGF0dHJpYnV0ZXMgd2hlbiBpdCANCj4gcmUtZXN0YWJs aXNoZXMgY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBjb250cm9sbGVyLiAgQnV0IHllcyBJIGRvIGFn cmVlIA0KPiB0aGF0IHRoZSBNQSBzZWVtcyB0byBuZWVkIGF0dHJpYnV0ZXMgdG8gY29tbXVuaWNh dGUgYXQgbGVhc3QgZW5vdWdoIA0KPiBpbmZvcm1hdGlvbiB0byB0aGUgY29udHJvbGxlciBhYm91 dCBpdHMgc3RhdHVzIGluIG9yZGVyIGZvciB0aGUgDQo+IGNvbnRyb2xsZXIgdG8ga25vdyBpZiBp dCBuZWVkcyB0byBzZW5kIGEgbmV3IG9yIHVwZGF0ZWQgSW5zdHJ1Y3Rpb24gc2V0Lg0KPiANCj4g SmFzb24NCj4gDQo+IE9uIDUvMTMvMTUsIDQ6MjEgUE0sICJDYXJleSwgVGltb3RoeSAoVGltb3Ro eSkiDQo+IDx0aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+IA0KPiA+ SmFzb24sDQo+ID4NCj4gPlN1cHByZXNzaW9uIGlzIGFuIGFkbWluaXN0cmF0aXZlIGFjdGlvbiB0 YWtlbiB0aHJvdWdoIGFuIGluc3RydWN0aW9uIA0KPiA+YnkgdGhlIGNvbnRyb2xsZXIuIExvc3Mg b2YgY29ubmVjdGl2aXR5IChkaXNhYmxlIHNjaGVkdWxlIG9yIHRhc2spIGlzIA0KPiA+YW4gYXV0 b25vbW91cyBvcGVyYXRpb25hbCBhY3Rpb24gdGFrZW4gYnkgdGhlIE1BLiBUaGUgcHJvYmxlbSBp cyANCj4gPnJlcG9ydGluZyBhbmQgcmVjb3ZlcnkgLSBIb3cgZG9lcyBhIG1hbmFnZW1lbnQgc3lz dGVtIGtub3csIGluIG9yZGVyIA0KPiA+dG8gdHJvdWJsZXNob290IG9yIHJlbWVkaWF0ZSB0aGUg ZXZlbnQsIGlmIHRoZSBzY2hlZHVsZSBvciB0YXNrIA0KPiA+KGFsb25nIHdpdGggdGhlIHJlc3Vs dGluZyBzY2hlZHVsZWQgYWN0aW9ucykgaGF2ZSBiZWVuIGRpc2FibGVkIGR1ZSANCj4gPnRvIGFu IGFkbWluaXN0cmF0aXZlIGFjdGlvbiBsaWtlIHN1cHByZXNzaW9uIG9yIHZpYSBhbiBhdXRvbm9t b3VzIA0KPiA+YWN0aW9uIGxpa2UgbG9zcyBvZiBjb25uZWN0aXZpdHkuDQo+ID4NCj4gPklmIHdl IHdvdWxkIGNob29zZSB0byB0cmVhdCB0aGUgcmVzdWx0IG9mIHRoZSBsb3NzIG9mIGNvbm5lY3Rp dml0eSBhcyANCj4gPmFuIGF1dG9ub21vdXMgc3VwcHJlc3Npb24gZXZlbnQgLSBJIGFtIGZpbmUg d2l0aCB0aGF0IGJ1dCB3ZSBuZWVkIHRoZSANCj4gPk1BIHRvIGJlIGFibGUgdG8gcmVwb3J0IHRo YXQgdGhlIHRhc2ssIHNjaGVkdWxlIGFuZCByZXN1bHRpbmcgDQo+ID5zY2hlZHVsZWQgYWN0aW9u cyBhcmUgYXV0b25vbW91c2x5IHN1cHByZXNzZWQgKHdoYXQgSSBjYWxsZWQgDQo+ID5kaXNhYmxl ZCkuIExpa2V3aXNlIHdlIHNob3VsZCByZXBvcnQgdGhhdCB0aGUgTUEgaXMgZGVncmFkZWQgYmVj YXVzZSANCj4gPml0IGN1cnJlbnRseSBpcyBiZWluZyBhdXRvbm9tb3VzbHkgb3IgYWRtaW5pc3Ry YXRpdmVseSBzdXBwcmVzc2VkLiANCj4gPlRoZSBNQSB3aWxsIGF0IGxlYXN0IG5lZWQgdG8gcmVl dmFsdWF0ZSBpdHMgY29uZGl0aW9ucyBvbmNlIG9uZSBjbGVhcnMgdG8gZmlndXJlIG91dCBpdHMg bmV3IHN0YXR1cy4NCj4gPg0KPiA+Q29tZSB0byB0aGluayBvZiBpdCAtIGNhbiBhIHN5c3RlbSBv dGhlciB0aGFuIHRoZSBjb250cm9sbGVyIGhhdmUgDQo+ID5hY2Nlc3MgdG8gdGhlIExNQVAgc3Rh dHVzIGluZm9ybWF0aW9uPw0KPiANCj4gV29u4oCZdCB0aGUgb25seSBzb3VyY2Ugb2YgdGhlIGxv Z2dpbmcgaW5mb3JtYXRpb24gYmV0IHRoZSBsYXN0IA0KPiBjb250cm9sbGVyIGNvbmZpZ3VyZWQg b24gdGhlIE1BPw0KPiANCj4gPkkgZ3Vlc3MgdGhpcyBhbGwgbXV0ZSBpZiB0aGUgb25seSBzeXN0 ZW0gYWxsb3dlZCBhY2Nlc3MgdG8gdGhlIHN0YXR1cyANCj4gPmluZm9ybWF0aW9uIGlzIHRoZSBj b250cm9sbGVyIHRoYXQgdGhlIE1BIGNhbid0IGFjY2VzcyB3aXRoIExvc3Mgb2YgDQo+ID5jb25u ZWN0aXZpdHkuIEluIFRSLTA2OSB0aGlzIGlzIHBvc3NpYmxlIHNpbmNlIHRoZSBjb250cm9sbGVy IGNhbiBiZSANCj4gPmRpZmZlcmVudCBmcm9tIHRoZSBBQ1MgYW5kIHdlIGNhbiBoYXZlIG90aGVy IHN5c3RlbXMgdGhhdCBjYW4gYWNjZXNzIA0KPiA+dGhlIGRhdGEuIEknbSBndWVzc2luZyBORVRD b25mL1JFU1RDb25mIGFsbG93cyB0aGUgc2FtZS4NCj4gPg0KPiA+QlIsDQo+ID5UaW0NCj4gPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBXZWlsLCBKYXNvbiBbbWFpbHRvOmph c29uLndlaWxAdHdjYWJsZS5jb21dDQo+ID5TZW50OiBXZWRuZXNkYXksIE1heSAxMywgMjAxNSAy OjU0IFBNDQo+ID5UbzogQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpOyBKdWVyZ2VuIFNjaG9lbndh ZWxkZXINCj4gPkNjOiBsbWFwQGlldGYub3JnDQo+ID5TdWJqZWN0OiBSZTogW2xtYXBdIGRyYWZ0 LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0wNTogQ29udHJvbGxlciANCj4gPnRpbWVvdXQN Cj4gPg0KPiA+SSBhbSBub3QgZXhhY3RseSBjbGVhciB3aGF0IHRoZSBkaWZmZXJlbmNlIGlzIGJl dHdlZW4gZGlzYWJsZWQgYW5kIA0KPiA+c3VwcHJlc3NlZCB0YXNrcyBvciBzY2hlZHVsZXMuIEl0 IHdvdWxkIHNlZW0gdGhhdCBzdXBwcmVzc2lvbiBpcyBhIA0KPiA+Z29vZCBmaXQgZm9yIHRoZSBj YXNlIG9mIGxvc3Mgb2YgY29ubmVjdGl2aXR5IGZyb20gdGhlIHdheSBpdCBpcyANCj4gPmRlc2Ny aWJlZCBpbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwgd2hlbiB0aGUgdGhlIA0KPiA+bWEtY29udHJv bGxlci1sb3N0LXRpbWVvdXQgY291bnRlciBleHBpcmVzLiBHaXZlbiB0aGlzIGZvbGxvd2luZyBu b3RlIA0KPiA+aW4gMy4zICgiTm90ZSB0aGF0IFN1cHByZXNzaW9uIGhhcyBubyBlZmZlY3Qgb24g ZWl0aGVyIENvbnRyb2xsZXIgDQo+ID5UYXNrcyBvciBDb250cm9sbGVyIFNjaGVkdWxlcy7Csikg aXQgd291bGQgY2xlYXJseSBub3QgaW1wYWN0IGZ1dHVyZSANCj4gPmF0dGVtcHRzIHRvIHJlLWVz dGFibGlzaCBjb25uZWN0aXZpdHkgdG8gdGhlIENvbnRyb2xsZXIgYW5kIHN0YXJ0IA0KPiA+dGVz dGluZyB3aGVyZSBpdCBsZWZ0IG9mZi4gVGhpcyBtYXkgYWxzbyBiZW5lZml0IGFuIG9wZXJhdG9y IGJ5IA0KPiA+b2ZmZXJpbmcgZmluZXIgY29udHJvbCBvdmVyIHdoaWNoIHRlc3RzIHNob3VsZCBi ZSBzdXBwcmVzc2VkIGFuZCANCj4gPndoaWNoIHNob3VsZG7CuXQgaW4gdGhlIGV2ZW50IG9mIGxv c3Mgb2YgY29ubmVjdGl2aXR5IHRvIHRoZSANCj4gPmNvbnRyb2xsZXIuIEZvciBleGFtcGxlIGlm IG1heSBiZSBvZiBiZW5lZml0IGZvciB0cm91Ymxlc2hvb3RpbmcgYW4gDQo+ID5pc3N1ZSB0byBo YXZlIGEgY2VydGFpbiBzdWJzZXQgb2YgdGVzdHMgY29udGludWUgcnVubmluZyBhbmQgY29sbGVj dGluZyBkYXRhIGV2ZW4gd2hlbiBjb25uZWN0aXZpdHkgdG8gdGhlIGNvbnRyb2xsZXIgaXMgbm90 IGF2YWlsYWJsZS4NCj4gPg0KPiA+SmFzb24NCj4gPg0KPiA+T24gNS8xMy8xNSwgODozNyBBTSwg IkNhcmV5LCBUaW1vdGh5IChUaW1vdGh5KSINCj4gPjx0aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVj ZW50LmNvbT4gd3JvdGU6DQo+ID4NCj4gPj5KdWVyZ2VuLA0KPiA+Pg0KPiA+PklmIHlvdSBkbyBu b3Qgd2FudCB0byBkaXNhYmxlIHRoZSBzY2hlZHVsZWQgdGFza3MgLSBJIHdvdWxkIGFjdHVhbGx5 IA0KPiA+PnNheSB0aGUgUGFyZW50IHRhc2tzIG5vdCB0aGUgc2NoZWR1bGVzIGFyZSBkaXNhYmxl ZC4gVGhlIHJlYXNvbiBpcyANCj4gPj5iZWNhdXNlIHdlIGFyZSB0YWxraW5nIGFib3V0IHdhbnRl ZCB0byBkaXNhYmxlIFRhc2tzIHRoYXQgYXJlIG5vdCANCj4gPj5yZWxhdGVkIHRvIHRoZSBjb21t dW5pY2F0aW9uIGJldHdlZW4gdGhlIE1BIGFuZCBDb250cm9sbGVyIG9yIHByb3BlciANCj4gPj5m dW5jdGlvbmluZyBvZiB0aGUgTUEuICBUaGUgTUEga25vd3MgdGhpcyBhcyBwYXJ0IG9mIHRoZWly IA0KPiA+PlRhc2tDYXBhYmlsaXR5IHJlcG9ydGluZyAod2hpY2ggc29tZWhvdyBnb3QgZGVsZXRl ZCBpbiBkcmFmdCAwNSkuDQo+ID4+DQo+ID4+QXMgdG8gdGhlIHJlcG9ydGluZyBvZiB0aGUgc3Rh dHVzIEkgd291bGQgZG8gdGhlIGZvbGxvd2luZzoNCj4gPj5BZGQgYW4gT3BlcmF0aW9uYWxTdGF0 dXMgYXR0cmlidXRlIHdpdGggdGhlIGZvbGxvd2luZyB2YWx1ZXMgdG8gdGhlIA0KPiA+PmFjdGlv biBvYmplY3QgKHdoaWNoIHdhcyBzY2hlZHVsZWQgdGFzayk6IGVuYWJsZWQsIA0KPiA+PmRpc2Fi bGVkLXNjaGVkdWxlLCBkaXNhYmxlZC10YXNrLCBkaXNhYmxlZC1vdGhlci4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj5JIHdvdWxkIGFsc28gYWRkIGFuIE9wZXJhdGlvbmFsU3RhdHVzIHRvOg0KPiA+ PjEpIFNjaGVkdWxlIG9iamVjdCB3aXRoIHRoZSBmb2xsb3dpbmcgdmFsdWVzOiBlbmFibGVkLCAN Cj4gPj5kaXNhYmxlZC1zdXBwcmVzc2VkLCBkaXNhYmxlZC1vdGhlci4NCj4gPj4yKSBUYXNrIG9i amVjdCAoSSBndWVzcyBpdCBjb3VsZCBnbyBpbiBUYXNrIFN0YXR1cykgd2l0aCB0aGUgDQo+ID4+ Zm9sbG93aW5nDQo+ID4+dmFsdWVzOiBlbmFibGVkLCBkaXNhYmxlZC1zdXBwcmVzc2VkLCBkaXNh YmxlZC1tYSwgZGlzYWJsZWQtb3RoZXIuDQo+ID4+MykgTWVhc3VyZW1lbnQgQWdlbnQgb2JqZWN0 IHdpdGggdGhlIGZvbGxvd2luZyB2YWx1ZXM6IGVuYWJsZWQsIA0KPiA+PmRlZ3JhZGVkLWNvbnRy b2xsZXItY29tbXVuaWNhdGlvbiwgZGVncmFkZWQtb3RoZXIsIGRpc2FibGVkLg0KPiA+Pg0KPiA+ PldlIHdvdWxkIGFsd2F5cyBpbmNsdWRlIGEgZGlzYWJsZWQtb3RoZXIgdG8gYWxsb3cgb3RoZXIg Y29uZGl0aW9ucy4gDQo+ID4+Rm9yIGV4YW1wbGUgaW4gVFItMDY5IHdlIGhhdmUgdGhlIGNhcGFi aWxpdHkgdG8gYWRtaW5pc3RyYXRpdmVseSANCj4gPj5lbmFibGUvZGlzYWJsZSB0aGUgbXVsdGkt aW5zdGFuY2Ugb2JqZWN0cyBieSBjb252ZW50aW9ucyAtIHNvIGlmIGZvciANCj4gPj5zb21lIHJl YXNvbiB0aGVzZSB3ZXJlIGFkbWluaXN0cmF0aXZlbHkgZGlzYWJsZWQgLSB3ZSB3b3VsZCBzZXQg dGhlIA0KPiA+Pk9wZXJhdGlvbmFsU3RhdHVzIHRvIGRpc2FibGVkLW90aGVyIG9yIGp1c3QgZGlz YWJsZWQgZm9yIHRoZSBNQS4NCj4gPj4NCj4gPj5UaGVzZSBzdGF0dXMnIHdvdWxkIHByb3ZpZGUg YSBjbGVhciBvcGVyYXRpb25hbCBzdGF0dXMgb2YgdGhlIA0KPiA+PmVsZW1lbnRzIHRoYXQgY2Fu IGJlIGRpc2FibGVkIG9yIGRlZ3JhZGVkIGJhc2VkIG9uIHdoYXQgaXMgY3VycmVudGx5IA0KPiA+ PmRvY3VtZW50ZWQgaW4gdGhlIGZyYW1ld29yayBhbmQgaW5mb3JtYXRpb24gbW9kZWwuIEkgd291 bGQgc3VzcGVjdCANCj4gPj5hcyB3ZSBpbXBsZW1lbnQgcHJvdG9jb2xzIHRoZXJlIG1pZ2h0IGJl IG90aGVyIHZhbHVlcyB3ZSB3YW50IHRvIA0KPiA+PnN1cHBvcnQgLSBlLmcuLCBwcm9ibGVtcyB3 aXRoIHRoZSBjb2xsZWN0b3ItTUEgY29tbXVuaWNhdGlvbi4uLg0KPiA+Pg0KPiA+PkJSLA0KPiA+ PlRpbQ0KPiA+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+RnJvbTogSnVlcmdlbiBT Y2hvZW53YWVsZGVyDQo+ID4+W21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGVdDQo+ID4+U2VudDogVHVlc2RheSwgTWF5IDEyLCAyMDE1IDk6MjAgQU0NCj4gPj5Ubzog Q2FyZXksIFRpbW90aHkgKFRpbW90aHkpDQo+ID4+Q2M6IGxtYXBAaWV0Zi5vcmcNCj4gPj5TdWJq ZWN0OiBSZTogW2xtYXBdIGRyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0wNTogQ29u dHJvbGxlciANCj4gPj50aW1lb3V0DQo+ID4+DQo+ID4+T24gVHVlLCBNYXkgMTIsIDIwMTUgYXQg MDE6MDQ6NDlQTSArMDAwMCwgQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpIHdyb3RlOg0KPiA+Pg0K PiA+Pj4gU28gZG9lcyB0aGF0IG5vdyBtZWFuIHdlIG5lZWQgdG8gaGF2ZSBhIG9wZXJhdGlvbmFs IHN0YXR1cyBub3cgZm9yIA0KPiA+Pj4gYSBzY2hlZHVsZWQgdGFzaz8gSSBjYW4gc2VlIGl0IG5v dyBhcyBhdHRyaWJ1dGUgd2l0aCB2YWx1ZXMgbGlrZToNCj4gPj4+IGVuYWJsZWQsIGRpc2FibGVk LCBzdXBwcmVzc2VkIGFuZCBlcnJvcmVkIG9yIHBvc3NpYmx5IGEgY29uZGl0aW9ucyANCj4gPj4+ IG9iamVjdD8NCj4gPj4NCj4gPj5JIHRoaW5rIHRoZXJlIHR3byBxdWVzdGlvbnMgaGVyZToNCj4g Pj4NCj4gPj5hKSBJZiBJIGxvb3NlIGNvbm5lY3Rpdml0eSwgZG8gSSBkaXNhYmxlIGFsbCBzY2hl ZHVsZXMgKGFuZCB0aHVzDQo+ID4+ICAgaW1wbGljaXRlbHkgYWxsIGFjdGlvbnMpIG9yIGRvIEkg ZGlzYWJsZSBzY2hlZHVsZWQgdGFza3M/IE15IGlkZWENCj4gPj4gICB3YXMgdG8gc2ltcGx5IGRp c2FibGUgYWxsIHNjaGVkdWxlcyAoYW5kIGFzIHN1Y2ggdGhlIHNjaGVkdWxlcyBoYXZlDQo+ID4+ ICAgdGhlaXIgc3RhdGUgY2hhbmdlZCB0byBkaXNhYmxlZCkuDQo+ID4+DQo+ID4+ICAgVGhlIHN1 cHByZXNzaW9uIG1lY2hhbmlzbSBjYW4gc3VwcHJlc3MgYm90aCBhIGxpc3Qgb2YgdGFza3MgYW5k IGENCj4gPj4gICBsaXN0IG9mIHNjaGVkdWxlcyBhbmQgaXQgaXMgY29uZmlndXJhYmxlIHdoYXQg aXMgYmVpbmcgc3VwcHJlc3NlZC4NCj4gPj4NCj4gPj4gICBPbmUgb3B0aW9uIGlzIHRoYXQgbG9z cyBvZiBjb25uZWN0aXZpdHkgc2ltcGx5IGNhdXNlcyBzdXBwcmVzc2lvbg0KPiA+PiAgIHRvIGJl IGFjdGl2YXRlZC4gQW5vdGhlciBvcHRpb24gaXMgdGhhdCBsb3NzIG9mIGNvbm5lY3Rpdml0eQ0K PiA+PiAgIHN1cHJlc3NlcyBhbGwgdGFza3MgdGhhdCBhcmUgbm90IGVzc2VudGlhbCBmb3IgY29t bXVuaWNhdGlvbiB3aXRoIGENCj4gPj4gICBjb250cm9sbGVyIGFuZCBob3VzZSBrZWVwaW5nLiBB bm90aGVyIG9wdGlvbiBpcyB0aGF0IGxvc3Mgb2YNCj4gPj4gICBjb25uZWN0aXZpdHkgc3VwcHJl c3NlcyBhbGwgc2NoZWR1bGVzLiBXZSBuZWVkIHRvIHNlbGVjdCBvbmUuDQo+ID4+DQo+ID4+Yikg RG8gd2UgZXhwb3NlIHRoZSBpbnRlcm5hbCBzdGF0ZSB0aGF0IGlzIG1haW50YWluZWQ/IFJpZ2h0 IG5vdywgd2UNCj4gPj4gICBkbyBub3QgZXhwb3NlIGFueSBvcGVyYXRpb25hbCBzdGF0ZSBmb3Ig c2NoZWR1bGVzLiBCdXQgd2UgZG8gZXhwb3NlDQo+ID4+ICAgb3BlcmF0aW9uYWwgc3RhdGUgZm9y IHRhc2tzLiBJZiBsb3NzIG9mIGNvbm5lY3Rpdml0eSBtZWFucyB3ZQ0KPiA+PiAgIGRpc2FibGUg YWxsIHRhc2tzIHRoYXQgYXJlIG5vdCBlc3NlbnRpYWwgZm9yIGNvbW11bmljYXRpb24gd2l0aCBh DQo+ID4+ICAgY29udHJvbGxlciBhbmQgaG91c2Uga2VlcGluZywgdGhhbiBleHBvc2luZyB0aGF0 IGluZm9ybWF0aW9uIHdvdWxkDQo+ID4+ICAgYmUgYSByYXRoZXIgbWlub3IgY2hhbmdlIHRvIHRo ZSBpbmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbC4NCj4gPj4NCj4gPj4gICBBIHRhc2sgc3RhdGUg d291bGQgdGhlbiBiZSBlbmFibGVkIChkZWZhdWx0KSwgc3VwcHJlc3NlZCBvcg0KPiA+PiAgIGRp c2FibGVkLiBFcnJvciBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGNvdmVyZWQgaW4gdGhlIGxhc3Qt ZmFpbGVkDQo+ID4+ICAgYXR0cmlidXRlcyBvZiBhIHRhc2suIChBbmQgdGhpcyBpcyB1c2VmdWwg aW4gc2l0dWF0aW9ucyB3aGVyZSB0YXNrcw0KPiA+PiAgIGZhaWwgb2NjYXNpb25hbGx5IHNvIHlv dSBjYW4gZ2V0IGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYXN0IGZhaWx1cmUNCj4gPj4gICBldmVu IHRob3VnaCB0aGUgdGFzayBpcyB3b3JraW5nIGZpbmUgcmlnaHQgbm93KS4NCj4gPj4NCj4gPj4v anMNCj4gPj4NCj4gPj4tLQ0KPiA+Pkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+PkZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KPiA+Pg0KPiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+bG1hcCBtYWlsaW5nIGxpc3QNCj4gPj5sbWFwQGlldGYub3JnDQo+ID4+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sbWFwDQo+ID4NCj4gPg0KPiA+VGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUgDQo+ID5wcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsLCBvciANCj4gPnN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0 byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgDQo+ID5pbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IA0KPiA+ aXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo aXMgRS1tYWlsLCANCj4gPnlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiwgDQo+ID5jb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVs YXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCANCj4gPmF0dGFjaG1lbnRzIHRvIHRoaXMgRS1t YWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSANCj4gPnVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSANCj4g PnRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+IA0KPiAN Cj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGlt ZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkg cHJpbnRvdXQuDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMg VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIw MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Mon Jul 6 05:40:14 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A741ACEBE for ; Mon, 6 Jul 2015 05:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbapHx5ioars for ; Mon, 6 Jul 2015 05:40:07 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 788771AD06F for ; Mon, 6 Jul 2015 05:40:07 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 76B05E02D5047; Mon, 6 Jul 2015 12:40:02 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t66CduAq017823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 12:40:03 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 08:39:56 -0400 From: "Carey, Timothy (Timothy)" To: Juergen Schoenwaelder Thread-Topic: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities Thread-Index: AQHQtQYblerhvmmR+Emt5rEWmPZzVZ3OXP0ggABKtID//70i4A== Date: Mon, 6 Jul 2015 12:39:56 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC20B35E@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150702203116.GA5561@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC20B29A@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150706122903.GA972@elstar.local> In-Reply-To: <20150706122903.GA972@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: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:40:13 -0000 Juergen, inline -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, July 06, 2015 7:29 AM To: Carey, Timothy (Timothy) Cc: lmap@ietf.org Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilit= ies On Mon, Jul 06, 2015 at 12:15:29PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, >=20 > The conditions associated with the task where when this task was executed= what were the conditions (possibly things like WAN link down, not enough m= emory for the task to execute, cross traffic occurred during the task) that= resulted in the task's status. But is this not captured in ma-task-last-status / ma-task-last-message and = ma-task-last-failed-status / ma-task-last-failed-message? No their can be many conditions that result in say a failed task. The= se string messages are singleton =20 > Likewise in the MA - the conditions are the conditions of the MA at the t= ime of retrieval (e.g., unable to connect to collector). In the new model, would this not simply be reported as a task failure? What are the MA specific conditions? We had in another thread a proposal to= have an MA status object. What else would be needed? Perhaps we are fine if we can get number of states defined that we need to = distinguish. Again there are times when there are multiple conditions that feed in= to the current status of an MA. I think if you have a MA operational status= it should be fine but I would like to hear what others think. > At first we had certain conditions spelled out in the information model b= ut we moved them in "generic" implementation specific conditions. >=20 > Finally the supported tasks are simply the tasks (tests) that the MA is a= ble to execute (name, role and URI of the registry). A controller will need= to know this in order to ask a MA to execute a task. Yes, this makes sense. But it does not feel right to associate status codes= returned by actions with the static task list that serves as an inventory = - they IMHO should be associated with actions. Yes you are correct that status should be associated with the last ac= tion executed for task - which is why the names were "last" - they only wan= ted the "last" action. We can certainly make that more clear if it isn't. = In my model the description has it as the last status update of a scheduled= action that referenced this task.... /js =20 > Hope that helps, >=20 > Tim >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 02, 2015 3:31 PM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task=20 > capabilities >=20 > Tim, >=20 > I am not exactly sure what you are missing. In -04 we had this: >=20 > object { > string ma-task-name; > string ma-task-role; > uri ma-task-registry; > datetime ma-task-last-invocation; > datetime ma-task-last-successful; > string ma-task-last-successful-message; > datetime ma-task-last-failed; > string ma-task-last-failed-message; > [ma-condition-obj ma-task-conditions<0..*>]; > } ma-task-status-obj >=20 > object { > int ma-condition-code; > string ma-condition-text; > } ma-condition-obj >=20 > It was unclear what this means. What are the N ma-condition-objs associat= ed to a task representing? So we clarified it by reporting the status code = together with the last completion and the last failed completion. Hence we = now have this: >=20 > object { > string ma-task-name; > uri ma-task-registry-entries<1..*>; > [string ma-task-role<0..*>;] > datetime ma-task-last-invocation; > datetime ma-task-last-completion; > =3D=3D> int ma-task-last-status; > string ma-task-last-message; > datetime ma-task-last-failed-completion; > =3D=3D> int ma-task-last-failed-status; > string ma-task-last-failed-message; > } ma-task-status-obj; >=20 > We also had M ma-condition-objs associated with the MA itself. >=20 > object { > uuid ma-agent-id; > urn ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > ma-task-capability-obj ma-supported-tasks<0..*>; > datetime ma-last-started; > [ma-condition-obj ma-conditions<0..*>;] > [ma-task-status-obj ma-task-status<0..*>;] > } ma-status-obj; >=20 > Again, it is unclear what these would be and report. So we removed them a= nd now we have this instead: >=20 > object { > uuid ma-agent-id; > uri ma-device-id; > string ma-hardware; > string ma-firmware; > string ma-version; > ma-interface-obj ma-interfaces<0..*>; > datetime ma-last-started; > [ma-task-status-obj ma-task-status<0..*>;] > } ma-status-obj; >=20 > Does this explanation make sense? If not, can you explain what you though= t the previous definitions would contain? >=20 > /js >=20 > On Fri, May 15, 2015 at 12:07:25PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > >=20 > > Any idea on why the task capabilities and conditions were removed from = the MA status in the information model? > >=20 > > Thanks, > > Tim > >=20 > > From: Carey, Timothy (Timothy) > > Sent: Monday, May 11, 2015 2:33 PM > > To: lmap@ietf.org > > Subject: draft-ietf-lmap-information-model-05: MA task capabilities > >=20 > > Team, > >=20 > > I was reviewing draft-ietf-lmap-information-model-05 and had a question= on the what happened to the task capabilities and conditions as part of th= e MA status. The text is still in the draft but the elements are gone... > >=20 > > Any help would be appreciated > >=20 > > Thanks, > > Tim > >=20 >=20 > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=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 --=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 Jul 6 05:42:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835771ACF07 for ; Mon, 6 Jul 2015 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDDjcqWjvPEc for ; Mon, 6 Jul 2015 05:41:58 -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 367531ACECB for ; Mon, 6 Jul 2015 05:41:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7165E8C6; Mon, 6 Jul 2015 14:41:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 239EL4f1mjLm; Mon, 6 Jul 2015 14:41:56 +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, 6 Jul 2015 14:41:55 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 625B220031; Mon, 6 Jul 2015 14:41:56 +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 7k3QcO1GvxI6; Mon, 6 Jul 2015 14:41:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C5062002B; Mon, 6 Jul 2015 14:41:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 37EC634EEC78; Mon, 6 Jul 2015 14:41:52 +0200 (CEST) Date: Mon, 6 Jul 2015 14:41:52 +0200 From: Juergen Schoenwaelder To: Trevor Burbridge , lmap@ietf.org Message-ID: <20150706124152.GA1042@elstar.local> Mail-Followup-To: Trevor Burbridge , lmap@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [lmap] definition of Instruction Task unclear X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:41:59 -0000 Hi, the information model uses the term "Instruction Task" in a few places but it is unclear what this term means or how an Instruction Task differs from a Measurement Task (which is a defined term, see the framework document). Trevor, do you recall the details? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 6 05:46:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636B11ACECD for ; Mon, 6 Jul 2015 05:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk34-LjgAbuX for ; Mon, 6 Jul 2015 05:46:10 -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 9F8A61ACECB for ; Mon, 6 Jul 2015 05:46: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 D969E1033; Mon, 6 Jul 2015 14:46:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id R0GYCAuase8x; Mon, 6 Jul 2015 14:46:07 +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, 6 Jul 2015 14:46:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89FDB2002B; Mon, 6 Jul 2015 14:46:07 +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 vIeI0L8smoIe; Mon, 6 Jul 2015 14:46:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 312D120013; Mon, 6 Jul 2015 14:46:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EED4734EECBC; Mon, 6 Jul 2015 14:46:02 +0200 (CEST) Date: Mon, 6 Jul 2015 14:46:02 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Timothy)" Message-ID: <20150706124600.GB1092@elstar.local> Mail-Followup-To: "Carey, Timothy (Timothy)" , "lmap@ietf.org" References: <9966516C6EB5FC4381E05BF80AA55F77BA2640A2@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150702203116.GA5561@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC20B29A@US70UWXCHMBA05.zam.alcatel-lucent.com> <20150706122903.GA972@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77DC20B35E@US70UWXCHMBA05.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC20B35E@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:46:11 -0000 On Mon, Jul 06, 2015 at 12:39:56PM +0000, Carey, Timothy (Timothy) wrote: > Juergen, > > inline > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, July 06, 2015 7:29 AM > To: Carey, Timothy (Timothy) > Cc: lmap@ietf.org > Subject: Re: [lmap] draft-ietf-lmap-information-model-05: MA task capabilities > > On Mon, Jul 06, 2015 at 12:15:29PM +0000, Carey, Timothy (Timothy) wrote: > > Juergen, > > > > The conditions associated with the task where when this task was executed what were the conditions (possibly things like WAN link down, not enough memory for the task to execute, cross traffic occurred during the task) that resulted in the task's status. > > But is this not captured in ma-task-last-status / ma-task-last-message and ma-task-last-failed-status / ma-task-last-failed-message? > No their can be many conditions that result in say a failed task. These string messages are singleton This is not an inventory of conditions but the specific condition that lead to a failure. > Yes you are correct that status should be associated with the last action executed for task - which is why the names were "last" - they only wanted the "last" action. We can certainly make that more clear if it isn't. In my model the description has it as the last status update of a scheduled action that referenced this task.... The same task may be run from several different schedules and hence we loose information. Only one of them might lead to failures but if it is not clear which one, how do you debug this? /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 Jul 6 05:58:53 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38D1A1B1E for ; Mon, 6 Jul 2015 05:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okHp3MTjqWg5 for ; Mon, 6 Jul 2015 05:58:50 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A781B2AE7 for ; Mon, 6 Jul 2015 05:50:44 -0700 (PDT) Received: from E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Jul 2015 13:50:37 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 6 Jul 2015 13:50:42 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 6 Jul 2015 13:50:41 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.0995.031; Mon, 6 Jul 2015 13:50:41 +0100 From: To: , Thread-Topic: definition of Instruction Task unclear Thread-Index: AQHQt+kmW+HYU5Fu5kupmuoPMBMVM53OZFhQ Date: Mon, 6 Jul 2015 12:50:40 +0000 Message-ID: <24f4735a0b15495c8936bf2fe85aa7b5@rew09926dag03c.domain1.systemhost.net> References: <20150706124152.GA1042@elstar.local> In-Reply-To: <20150706124152.GA1042@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] definition of Instruction Task unclear X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 12:58:52 -0000 Yes, Instruction Tasks were those used to update the Instruction - i.e. th= ose tasks involved in communication with the Controller. They are not subje= ct to suppression. Trevor. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 06 July 2015 13:42 To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org Subject: definition of Instruction Task unclear Hi, the information model uses the term "Instruction Task" in a few places but = it is unclear what this term means or how an Instruction Task differs from = a Measurement Task (which is a defined term, see the framework document). T= revor, do you recall the details? /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 Jul 6 06:04:08 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE01A1B3F for ; Mon, 6 Jul 2015 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0llfk_7EVf8e for ; Mon, 6 Jul 2015 06:04:05 -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 8A8C91A1B71 for ; Mon, 6 Jul 2015 05:59:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9DD591002; Mon, 6 Jul 2015 14:59:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id InCt8V9A8K2X; Mon, 6 Jul 2015 14:59:56 +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, 6 Jul 2015 14:59:55 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 187D52002B; Mon, 6 Jul 2015 14:59:56 +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 TeqvmBY-lDVl; Mon, 6 Jul 2015 14:59:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FCF220013; Mon, 6 Jul 2015 14:59:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB21C34EED3E; Mon, 6 Jul 2015 14:59:50 +0200 (CEST) Date: Mon, 6 Jul 2015 14:59:50 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20150706125950.GA1163@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: <20150706124152.GA1042@elstar.local> <24f4735a0b15495c8936bf2fe85aa7b5@rew09926dag03c.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24f4735a0b15495c8936bf2fe85aa7b5@rew09926dag03c.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] definition of Instruction Task unclear X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:04:06 -0000 Hm, but then what are "Instruction Task Configurations", the first numbered bullet in 3.3.? And what about this text: The explicit Suppression instruction message is able to simply enable/disable all Instruction Tasks (that are enabled for default suppression) as well as having fine control on which Tasks are suppressed. It seems terminology is unclear or inconsistently used. I would prefer to reduce terms if possible. I would also remove the list in 2.B. in section 3 just above section 3.1. - having Control Tasks defined should be sufficient, no? /js On Mon, Jul 06, 2015 at 12:50:40PM +0000, trevor.burbridge@bt.com wrote: > Yes, Instruction Tasks were those used to update the Instruction - i.e. those tasks involved in communication with the Controller. They are not subject to suppression. > > Trevor. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 06 July 2015 13:42 > To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org > Subject: definition of Instruction Task unclear > > Hi, > > the information model uses the term "Instruction Task" in a few places but it is unclear what this term means or how an Instruction Task differs from a Measurement Task (which is a defined term, see the framework document). Trevor, do you recall the details? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- 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 Jul 6 06:45:53 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35AE1A86EE for ; Mon, 6 Jul 2015 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLDzUnXuPr6C for ; Mon, 6 Jul 2015 06:45:50 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0BD1A6F7C for ; Mon, 6 Jul 2015 06:45:50 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Jul 2015 14:45:45 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 6 Jul 2015 14:45:48 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 6 Jul 2015 14:45:46 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.0995.031; Mon, 6 Jul 2015 14:45:46 +0100 From: To: Thread-Topic: definition of Instruction Task unclear Thread-Index: AQHQt+kmW+HYU5Fu5kupmuoPMBMVM53OZFhQ///yWwCAABx4MA== Date: Mon, 6 Jul 2015 13:45:45 +0000 Message-ID: <224a2b6d15d54842b9cf842b40e22b78@rew09926dag03c.domain1.systemhost.net> References: <20150706124152.GA1042@elstar.local> <24f4735a0b15495c8936bf2fe85aa7b5@rew09926dag03c.domain1.systemhost.net> <20150706125950.GA1163@elstar.local> In-Reply-To: <20150706125950.GA1163@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] definition of Instruction Task unclear X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:45:53 -0000 Sorry - I take back my previous statement entirely. I meant Control Tasks! = Instruction Tasks are those executed by the Instruction as opposed to the C= onfiguration. This should be clear - under the Instruction object (ma-instr= uction-obj) there is a list of ma-instruction-tasks. Trevor. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 06 July 2015 14:00 To: Burbridge,T,Trevor,TUB8 R Cc: lmap@ietf.org Subject: Re: definition of Instruction Task unclear Hm, but then what are "Instruction Task Configurations", the first numbered= bullet in 3.3.? And what about this text: The explicit Suppression instruction message is able to simply enable/disable all Instruction Tasks (that are enabled for default suppression) as well as having fine control on which Tasks are suppressed. It seems terminology is unclear or inconsistently used. I would prefer to r= educe terms if possible. I would also remove the list in 2.B. in section 3 = just above section 3.1. - having Control Tasks defined should be sufficient= , no? /js On Mon, Jul 06, 2015 at 12:50:40PM +0000, trevor.burbridge@bt.com wrote: > Yes, Instruction Tasks were those used to update the Instruction - i.e. = those tasks involved in communication with the Controller. They are not sub= ject to suppression. >=20 > Trevor. >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 06 July 2015 13:42 > To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org > Subject: definition of Instruction Task unclear >=20 > Hi, >=20 > the information model uses the term "Instruction Task" in a few places bu= t it is unclear what this term means or how an Instruction Task differs fro= m a Measurement Task (which is a defined term, see the framework document).= Trevor, do you recall the details? >=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 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 Jul 14 20:39:12 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A18F1B3151 for ; Tue, 14 Jul 2015 20:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o96s71KrwPcJ for ; Tue, 14 Jul 2015 20:39:09 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1301B3150 for ; Tue, 14 Jul 2015 20:39:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosGAHvmdlXGmAcV/2dsb2JhbABcgkUhKlRkrF8BAQEBAQEGBZliAoFITAEBAQEBAYEAC4QkAQEDEhteAQwJFVYmAQQbGogMAZw/hQmufgwBH4YZiX+DT4EWBZM+jGCDe4J1hHSGfINbJGKDFoI1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,581,1427774400"; d="scan'208,217";a="129130092" 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 Jul 2015 23:39:07 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 14 Jul 2015 23:39:07 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Wed, 15 Jul 2015 05:39:06 +0200 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: WANTED - note takers, jabber scribes for the WG meeting at IETF 93 Thread-Index: AdC+r8wC0K3xYX6bR7ybEFD40oOHbA== Date: Wed, 15 Jul 2015 03:39:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA95868@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA95868AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] WANTED - note takers, jabber scribes for the WG meeting at IETF 93 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 03:39:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA95868AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For the WG session at IETF 93 we need two note takers and a jabber scribe. = Please volunteer in advance - your contribution to a successful meeting wil= l be appreciated. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA95868AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For the WG session at IETF 93 we need two note taker= s and a jabber scribe. Please volunteer in advance – your contributio= n to a successful meeting will be appreciated.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA95868AZFFEXMB04globa_-- From nobody Wed Jul 15 16:46:43 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D080C1ACE2B for ; Wed, 15 Jul 2015 16:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oTi0sn83p9c for ; Wed, 15 Jul 2015 16:46:40 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FEC1ACE20 for ; Wed, 15 Jul 2015 16:46:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowGAH3ldlXGmAcV/2dsb2JhbABcgkUhKlRkrF8BAQEBAQEGBZNphXkCgUhMAQEBAQEBgQALhCQBAQMSG14BDAkVViYBBBsaiAwBDJwxhQmufgEKAQEBGgSGGYl/LYMigRYFkz6MYIN7gnWPSyRigxaCNYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,581,1427774400"; d="scan'208,217";a="110402280" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jul 2015 19:46:37 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 15 Jul 2015 19:46:36 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 15 Jul 2015 19:46:35 -0400 From: "Romascanu, Dan (Dan)" To: "lmap@ietf.org" Thread-Topic: agenda for the LMAP meeting on 7/20 Thread-Index: AdC/WHn5KuPKzCy0TF2uJsSHO0QecQ== Date: Wed, 15 Jul 2015 23:46:35 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA980B5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA980B5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [lmap] agenda for the LMAP meeting on 7/20 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 23:46:42 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA980B5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The updated agenda of the LMAP meeting is available at https://www.ietf.org= /proceedings/93/agenda/agenda-93-lmap. The meeting is scheduled for Monday = morning, 9 to 11:30 AM CET. Unfortunately Juergen will not be able to atten= d the meeting. Please let me know who will drive the discussions on items #= 3, #4, #5 (Information Model, YANG Data Model, Protocol). Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA980B5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The updated agenda of the LMAP meeting is available = at https://www.ietf.org/proceedings/93/agenda/agenda-93-lmap. The meeting = is scheduled for Monday morning, 9 to 11:30 AM CET. Unfortunately Juergen w= ill not be able to attend the meeting. Please let me know who will drive th= e discussions on items # 3, #4, #5 (Information Model, YANG Data Model, Protocol).

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA980B5AZFFEXMB04globa_-- From nobody Sun Jul 19 14:57:04 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6D1B2DA1 for ; Sun, 19 Jul 2015 14:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwLChLM2EpuG for ; Sun, 19 Jul 2015 14:57:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA51A90F4 for ; Sun, 19 Jul 2015 14:57:01 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,504,1432612800"; d="scan'208";a="726959772" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Jul 2015 17:32:54 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sun, 19 Jul 2015 17:56:59 -0400 From: "Weil, Jason" To: "lmap@ietf.org" Date: Sun, 19 Jul 2015 17:56:59 -0400 Thread-Topic: [93all] IETF 93 - Agenda Changes Thread-Index: AdDCIBkEDHHAhUj3SsO5VYucZCZB5QATBXxp Message-ID: References: <20150719124019.24710.55522.idtracker@ietfa.amsl.com> In-Reply-To: <20150719124019.24710.55522.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lmap] FW: [93all] IETF 93 - Agenda Changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 21:57:03 -0000 Attention LMAP members, Please note the change in schedule for the LMAP WG meeting to a new date, t= ime and room. The new slot will result in 30 minutes less time for the meeting. An adjust= ed agenda will be circulated soon. LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona Thanks, Dan and Jason ________________________________________ From: 93all [93all-bounces@ietf.org] On Behalf Of IETF Agenda [agenda@ietf.= org] Sent: Sunday, July 19, 2015 8:40 AM To: IETF Announcement List Cc: 93all@ietf.org; ietf@ietf.org Subject: [93all] IETF 93 - Agenda Changes Hello Everyone! There are a few changes to the agenda that are detailed below. These change= s are reflected on the large agenda in the IETF registration area and on th= e web agenda. LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona Thursday 1520 to 1720 ROOM CHANGE - trill will be held in Karlin III ROOM CHANGE - manet will be held in Berlin/Brussels https://datatracker.ietf.org/meeting/93/agenda.txt https://datatracker.ietf.org/meeting/93/agenda.html Thank you! _______________________________________________ 93all mailing list 93all@ietf.org https://www.ietf.org/mailman/listinfo/93all This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Jul 20 00:25:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621B91A00B0 for ; Mon, 20 Jul 2015 00:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdjINwlm2g0Q for ; Mon, 20 Jul 2015 00:25:30 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id C30E11A00F5 for ; Mon, 20 Jul 2015 00:25:29 -0700 (PDT) From: Henning Schulzrinne To: "Weil, Jason" , "lmap@ietf.org" Thread-Topic: [93all] IETF 93 - Agenda Changes Thread-Index: AQHQwiAlhNQiwodn4U6rMXoVNQFZBp3jV2uAgACeObw= Date: Mon, 20 Jul 2015 07:25:26 +0000 Message-ID: References: <20150719124019.24710.55522.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: twcable.com; dkim=none (message not signed) header.d=none; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 5:TASqjjCdikudys2AKC6seM4TAFHftC3NGIDuZTcpBLVhGmgwlTlXQZyDDGU9FtW1RiO8v0dIV29TS220zKEugrOv8ehLT1omNAnXzMYObGXoSlyWMyajhnyZmcqmL7ylgKohyen5saBr5Po9WJgJoQ==; 24:adSqYe9X1myeUYIdmWcl3OdeiN+Z7kWjKK3Q+uA1c3dGPvc8s3e+CFc0UWBbiBFqxtlIx4D4HcF3/wYUFOIkCNKURhbkJg5cFwaXCM5etw4=; 20:ifxeYCy6XNPn+WxGkiQ2D4AxaOUk62H93NRNTruRMsQiDkKD0XO8wnaEtS2qlJsfKKypGJ+9Qpb4lowipBgXrQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634; cy1pr09mb0634: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0643BDA83C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(53754006)(377454003)(189998001)(54356999)(76176999)(5003600100002)(50986999)(86362001)(99286002)(19580405001)(46102003)(102836002)(106116001)(15975445007)(77096005)(77156002)(62966003)(5890100001)(76576001)(2501003)(2656002)(40100003)(122556002)(2900100001)(92566002)(2950100001)(87936001)(5001770100001)(74316001)(33656002)(5002640100001)(107886002)(5001960100002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2015 07:25:26.1546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [lmap] [93all] IETF 93 - Agenda Changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:25:31 -0000 I realize this sometimes can't be avoided, but I admit that I find this les= s-than-last-minute change to be less than helpful, given the need to someti= mes make travel plans that don't span the whole IETF week. Henning ________________________________________ From: lmap on behalf of Weil, Jason Sent: Sunday, July 19, 2015 5:56 PM To: lmap@ietf.org Subject: [lmap] FW: [93all] IETF 93 - Agenda Changes Attention LMAP members, Please note the change in schedule for the LMAP WG meeting to a new date, t= ime and room. The new slot will result in 30 minutes less time for the meeting. An adjust= ed agenda will be circulated soon. LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona Thanks, Dan and Jason ________________________________________ From: 93all [93all-bounces@ietf.org] On Behalf Of IETF Agenda [agenda@ietf.= org] Sent: Sunday, July 19, 2015 8:40 AM To: IETF Announcement List Cc: 93all@ietf.org; ietf@ietf.org Subject: [93all] IETF 93 - Agenda Changes Hello Everyone! There are a few changes to the agenda that are detailed below. These change= s are reflected on the large agenda in the IETF registration area and on th= e web agenda. LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona Thursday 1520 to 1720 ROOM CHANGE - trill will be held in Karlin III ROOM CHANGE - manet will be held in Berlin/Brussels https://datatracker.ietf.org/meeting/93/agenda.txt https://datatracker.ietf.org/meeting/93/agenda.html Thank you! _______________________________________________ 93all mailing list 93all@ietf.org https://www.ietf.org/mailman/listinfo/93all This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Mon Jul 20 00:58:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422A1A034F for ; Mon, 20 Jul 2015 00:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-J8eRGQHXAf for ; Mon, 20 Jul 2015 00:58:46 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCB41A0242 for ; Mon, 20 Jul 2015 00:58:46 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,507,1432612800"; d="scan'208";a="286569718" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Jul 2015 03:37:39 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 20 Jul 2015 03:58:44 -0400 From: "Weil, Jason" To: Henning Schulzrinne , "lmap@ietf.org" Date: Mon, 20 Jul 2015 03:58:42 -0400 Thread-Topic: [93all] IETF 93 - Agenda Changes Thread-Index: AdDCweXpyw7Hmw+wQSCHPGqfxM37lw== Message-ID: References: <20150719124019.24710.55522.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] [93all] IETF 93 - Agenda Changes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 07:58:48 -0000 In this case it was for the greater good of progressing WG items by ensuring editors of WG documents could participate in the discussion. We were originally scheduled for this Thursday slot in the preliminary agenda and moved at the end of June to Monday for scheduling reasons. The WG that moved into the Thursday spot cancelled that meeting on Sunday hence freeing up the initial slot again. The key decision to move to the freed up slot was to make allowance for presenters attendance for key chartered items that was not possible on Monday in the hopes of improving the discussion on these critical items. I completely agree it would have been beneficial to give a lengthier notification period, but in this instance that was not a possibility. Apologies, Jason On 7/20/15, 3:25 AM, "Henning Schulzrinne" wrote: >I realize this sometimes can't be avoided, but I admit that I find this >less-than-last-minute change to be less than helpful, given the need to >sometimes make travel plans that don't span the whole IETF week. > >Henning > >________________________________________ >From: lmap on behalf of Weil, Jason > >Sent: Sunday, July 19, 2015 5:56 PM >To: lmap@ietf.org >Subject: [lmap] FW: [93all] IETF 93 - Agenda Changes > >Attention LMAP members, > >Please note the change in schedule for the LMAP WG meeting to a new date, >time and room. >The new slot will result in 30 minutes less time for the meeting. An >adjusted agenda will be circulated soon. > >LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona > >Thanks, > >Dan and Jason >________________________________________ >From: 93all [93all-bounces@ietf.org] On Behalf Of IETF Agenda >[agenda@ietf.org] >Sent: Sunday, July 19, 2015 8:40 AM >To: IETF Announcement List >Cc: 93all@ietf.org; ietf@ietf.org >Subject: [93all] IETF 93 - Agenda Changes > >Hello Everyone! > >There are a few changes to the agenda that are detailed below. These >changes are reflected on the large agenda in the IETF registration area >and on the web agenda. > >LMAP - Moved FROM Monday 0900 TO Thursday 1520 in Athens/Barcelona > >Thursday 1520 to 1720 >ROOM CHANGE - trill will be held in Karlin III >ROOM CHANGE - manet will be held in Berlin/Brussels > >https://datatracker.ietf.org/meeting/93/agenda.txt >https://datatracker.ietf.org/meeting/93/agenda.html > >Thank you! > >_______________________________________________ >93all mailing list >93all@ietf.org >https://www.ietf.org/mailman/listinfo/93all > >This E-mail and any of its attachments may contain Time Warner Cable >proprietary information, which is privileged, confidential, or subject to >copyright belonging to Time Warner Cable. This E-mail is intended solely >for the use of the individual or entity to which it is addressed. If you >are not the intended recipient of this E-mail, you are hereby notified >that any dissemination, distribution, copying, or action taken in >relation to the contents of and attachments to this E-mail is strictly >prohibited and may be unlawful. If you have received this E-mail in >error, please notify the sender immediately and permanently delete the >original and any copy of this E-mail and any printout. > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Jul 20 07:12:32 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18371A8920 for ; Mon, 20 Jul 2015 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFiTz-7BvNJq for ; Mon, 20 Jul 2015 07:12:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BC71A891C for ; Mon, 20 Jul 2015 07:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+DtGxYzvAUtp1cJzb1LVKf6kxTM65IdAwAXwH5eJA3g=; b=kr3s0OvKm1ClcpT/tahcAUTyGgxhEsBL1kFFcWoZW6whOkzxRBuksYvxUXBVxW1zhHqb4qEjaSIp7umP+niOPQL+jiakab8pMqDwhd3nS2Km0z4pXE9NVbfHTnZa3H/w1TgWhOGDHI7NPPXEZov7Grbuv4ElhUtHAU7nd2PqcBU= Received: from BY1PR03MB1515.namprd03.prod.outlook.com (10.162.210.149) by BY1PR03MB1515.namprd03.prod.outlook.com (10.162.210.149) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 20 Jul 2015 14:12:03 +0000 Received: from BY1PR03MB1515.namprd03.prod.outlook.com ([10.162.210.149]) by BY1PR03MB1515.namprd03.prod.outlook.com ([10.162.210.149]) with mapi id 15.01.0219.018; Mon, 20 Jul 2015 14:12:03 +0000 From: Kamala Subramaniam To: "lmap@ietf.org" Thread-Topic: draft-ksubram-lmap-router-buffer-sizes-01 Thread-Index: AdDBP82bd9FJs3NxQsuKHvgbEId5Ew== Date: Mon, 20 Jul 2015 14:12:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [31.133.160.113] x-microsoft-exchange-diagnostics: 1; BY1PR03MB1515; 5:9tH91Fd5mMkf4Csw2QTbMGS3G9pHiY9yKYYxU3j/C2xxn6GBXLfYmL6Ov8Qyv8tipPs6gbmxb8HuMmI+nJ3txntQlkwPsYp3Om4iRp4OiPPf9V2DAQcnKA+8yJuFGzep7rjs6Ht7Ej8JwdhWho4eYA==; 24:86KxmYQVWJcne6mdZb8avRHqiEjBYBt7NbQDR7b0ud76MFfvwdlYllcCnfeFWmNDHXBScWY21x0UHkV86FIXpYQ9akvQqnsMRsbN2DYwqvQ=; 20:7KIxz0+gGISRYZ1jVvHO6x/K4C8Zmz+O7T7UATqIkzvF3FKMlepMTUBwLGBThuML1nPkXcO3dNky9IOtXxnw3A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1515; by1pr03mb1515: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY1PR03MB1515; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1515; x-forefront-prvs: 0643BDA83C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(46034005)(377454003)(19580395003)(40100003)(66066001)(46102003)(50986999)(86362001)(54356999)(19300405004)(87936001)(19580405001)(2656002)(74316001)(230783001)(77156002)(450100001)(62966003)(16236675004)(2351001)(122556002)(92566002)(15975445007)(2900100001)(2501003)(5003600100002)(77096005)(189998001)(107886002)(76576001)(102836002)(99286002)(110136002)(5001960100002)(33656002)(5002640100001)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1515; H:BY1PR03MB1515.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR03MB151582249FE93BDCE45C195DBC850BY1PR03MB1515namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2015 14:12:03.0201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1515 Archived-At: Subject: Re: [lmap] draft-ksubram-lmap-router-buffer-sizes-01 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:12:30 -0000 --_000_BY1PR03MB151582249FE93BDCE45C195DBC850BY1PR03MB1515namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LMAP WG, A new version of this draft has been posted. This includes an information m= odel that is needed to collect empirical data such that the analysis of rou= ter buffer sizes needed in the WAN will be easier. Additionally, I will als= o be presenting some data that will drive the point that both a model, as w= ell as metrics are lacking to this study. Your feedback is appreciated. Thanks, Kamala From: Kamala Subramaniam Sent: Monday, November 10, 2014 12:06 PM To: 'lmap@ietf.org' Subject: draft-ksubram-lmap-router-buffer-sizes-00 Dear LMAP WG, We have submitted a draft "Router Buffer Sizes in the WAN". It will be pres= ented this Thursday. I wanted to take this opportunity to introduce this dr= aft, and get some feedback. This draft has received some input from the AQM= WG. The lmap-use-cases draft is what initiated the request to be presented in t= he LMAP WG. Let me get more in to the details by elaborating the issue wit= h each of the 4 subsections in this ISP use case. Before that, maybe listing the goals would give a better idea: * Drive down the unit cost in $/GB by building efficient but cheaper = networks. Do our networks really need the buffers we deal with today at hig= h costs? * Maximize throughput in the backbone by always keeping the links bus= y so that the router buffers never underflow and the router does not lose t= hroughput. * To take into consideration variables such as {short Vs long flows, = packet sizes, queue depth/model, traffic classes, etc.} as factors while re= ducing the whistles, bells, and knobs to keep it simple to configure as wel= l as manage. Now, for the subsections: * Identifying, isolating and fixing problems: we observe that there a= re numerous issues at different layers that have an effect (directly or ind= irectly) on the sizing of router buffers. Could this be solved by high laye= r optimizations (ECN, tweaking TCP flows), or something like just a differ= ent queuing model. Studying the nature of the traffic that exists in an ISP= world today is an important way to determine this. Where really is this pr= oblem? Is it the way we design our networks for example by not taking into = consideration how scavenger class really affects us? * Design and planning: One the problem has been identified it becomes= easier to design and plan the networks. Perhaps all we need are small size= buffers driving down the cost. * Understanding the quality experienced by customers: again a huge ch= unk of the study would have packet discards (WAN facing/ outgoing egress in= terface perhaps?). Do the new methods involved in this study work better fo= r QoS? * Understanding the impact and operation of new devices and technolog= y: let's say that the conclusion of this study is that we do not need large= size buffers (we are talking 125MB per port), then can we convince the ven= dors (switch/router/chip) to go down that path. There have been many studies which provide theories to what the size should= be. However, most of these are theoretical in nature and do not take into = account any empirical data. While we continue to mine the big data availabl= e to us to further study this, we'd also like to start a draft which would = in the minimum entail a problem statement, get an idea of the amount of int= erest, and hopefully lead to some collaboration. Regards, Kamala --_000_BY1PR03MB151582249FE93BDCE45C195DBC850BY1PR03MB1515namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LMAP WG,

 

A new version of this = draft has been posted. This includes an information model that is needed to= collect empirical data such that the analysis of router buffer sizes neede= d in the WAN will be easier. Additionally, I will also be presenting some data that will drive the point that both a = model, as well as metrics are lacking to this study. Your feedback is appre= ciated.

 

Thanks,

Kamala

 

From: Kamala Subramaniam
Sent: Monday, November 10, 2014 12:06 PM
To: 'lmap@ietf.org' <lmap@ietf.org>
Subject: draft-ksubram-lmap-router-buffer-sizes-00

 

Dear LMAP WG,

 

We have submitted a dr= aft “Router Buffer Sizes in the WAN”. It will be presented this= Thursday. I wanted to take this opportunity to introduce this draft, and g= et some feedback. This draft has received some input from the AQM WG.

 

The lmap-use-cases dra= ft is what initiated the request to be presented in the LMAP WG.  Let = me get more in to the details by elaborating the issue with each of the 4 s= ubsections in this ISP use case.

 

Before that, maybe lis= ting the goals would give a better idea:

·    &n= bsp;  Drive down the unit cost in $/GB by building efficient = but cheaper networks. Do our networks really need the buffers we deal with = today at high costs?

·    &n= bsp;  Maximize throughput in the backbone by always keeping t= he links busy so that the router buffers never underflow and the router doe= s not lose throughput.

·    &n= bsp;  To take into consideration variables such as {short Vs = long flows, packet sizes, queue depth/model, traffic classes, etc.} as fact= ors while reducing the whistles, bells, and knobs to keep it simple to configure as well as manage.

Now, for the subsectio= ns:

·    &n= bsp;  Identifying, isolating and fixing problems: we observe = that there are numerous issues at different layers that have an effect (dir= ectly or indirectly) on the sizing of router buffers. Could this be solved by high layer optimizations (ECN, = tweaking TCP flows),  or something like just a different queuing model= . Studying the nature of the traffic that exists in an ISP world today is a= n important way to determine this. Where really is this problem? Is it the way we design our networks for example b= y not taking into consideration how scavenger class really affects us?=

·    &n= bsp;  Design and planning: One the problem has been identifie= d it becomes easier to design and plan the networks. Perhaps all we need ar= e small size buffers driving down the cost.

·    &n= bsp;  Understanding the quality experienced by customers: aga= in a huge chunk of the study would have packet discards (WAN facing/ outgoi= ng egress interface perhaps?). Do the new methods involved in this study work better for QoS?

·    &n= bsp;  Understanding the impact and operation of new devices a= nd technology: let’s say that the conclusion of this study is that we= do not need large size buffers (we are talking 125MB per port), then can we convince the vendors (switch/router/c= hip) to go down that path.

There have been many s= tudies which provide theories to what the size should be. However, most of = these are theoretical in nature and do not take into account any empirical = data. While we continue to mine the big data available to us to further study this, we’d also like to st= art a draft which would in the minimum entail a problem statement, get an i= dea of the amount of interest, and hopefully lead to some collaboration.

 

Regards,

Kamala

 

--_000_BY1PR03MB151582249FE93BDCE45C195DBC850BY1PR03MB1515namp_-- From nobody Wed Jul 22 04:35:50 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF11ACE6D for ; Wed, 22 Jul 2015 04:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAqlUr3YaGwM for ; Wed, 22 Jul 2015 04:35:46 -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 33BB51B2C24 for ; Wed, 22 Jul 2015 04:35:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 71C331535; Wed, 22 Jul 2015 13:35:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3anVyqMRsFvx; Wed, 22 Jul 2015 13:35:19 +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, 22 Jul 2015 13:35:19 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7917F2003A; Wed, 22 Jul 2015 13:35:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uGZK0BE2u4C5; Wed, 22 Jul 2015 13:35: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 57B3120039; Wed, 22 Jul 2015 13:35:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88F6435DD59E; Wed, 22 Jul 2015 13:35:18 +0200 (CEST) Date: Wed, 22 Jul 2015 13:35:15 +0200 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20150722113513.GA6968@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, lmap@ietf.org References: <20150706124152.GA1042@elstar.local> <24f4735a0b15495c8936bf2fe85aa7b5@rew09926dag03c.domain1.systemhost.net> <20150706125950.GA1163@elstar.local> <224a2b6d15d54842b9cf842b40e22b78@rew09926dag03c.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <224a2b6d15d54842b9cf842b40e22b78@rew09926dag03c.domain1.systemhost.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] definition of Instruction Task unclear X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:35:49 -0000 Hm, I did not find this clear. I would prefer to get rid of this term. /js On Mon, Jul 06, 2015 at 01:45:45PM +0000, trevor.burbridge@bt.com wrote: > Sorry - I take back my previous statement entirely. I meant Control Tasks! Instruction Tasks are those executed by the Instruction as opposed to the Configuration. This should be clear - under the Instruction object (ma-instruction-obj) there is a list of ma-instruction-tasks. > > Trevor. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 06 July 2015 14:00 > To: Burbridge,T,Trevor,TUB8 R > Cc: lmap@ietf.org > Subject: Re: definition of Instruction Task unclear > > Hm, but then what are "Instruction Task Configurations", the first numbered bullet in 3.3.? And what about this text: > > The explicit Suppression instruction message is able to simply > enable/disable all Instruction Tasks (that are enabled for default > suppression) as well as having fine control on which Tasks are > suppressed. > > It seems terminology is unclear or inconsistently used. I would prefer to reduce terms if possible. I would also remove the list in 2.B. in section 3 just above section 3.1. - having Control Tasks defined should be sufficient, no? > > /js > > On Mon, Jul 06, 2015 at 12:50:40PM +0000, trevor.burbridge@bt.com wrote: > > Yes, Instruction Tasks were those used to update the Instruction - i.e. those tasks involved in communication with the Controller. They are not subject to suppression. > > > > Trevor. > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: 06 July 2015 13:42 > > To: Burbridge,T,Trevor,TUB8 R; lmap@ietf.org > > Subject: definition of Instruction Task unclear > > > > Hi, > > > > the information model uses the term "Instruction Task" in a few places but it is unclear what this term means or how an Instruction Task differs from a Measurement Task (which is a defined term, see the framework document). Trevor, do you recall the details? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > 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 Thu Jul 23 10:30:25 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F50E1A8B84 for ; Thu, 23 Jul 2015 10:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGznmnQw5t49 for ; Thu, 23 Jul 2015 10:30:14 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095CD1A8928 for ; Thu, 23 Jul 2015 10:30:13 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Jul 2015 18:30:09 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 23 Jul 2015 18:30:11 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Jul 2015 18:30:10 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Thu, 23 Jul 2015 18:30:10 +0100 From: To: Thread-Topic: Multiple metrics measured on same active measurement traffic. Thread-Index: AQHQxW0eVNepC19p7UKtN/k0Qzp2aw== Date: Thu, 23 Jul 2015 17:30:10 +0000 Message-ID: <1437672627442.77643@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.187.101.42] Content-Type: multipart/alternative; boundary="_000_143767262744277643btcom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 17:30:22 -0000 --_000_143767262744277643btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was just discussing with Al and Marcelo the issue of when you want to mea= sure multiple metrics from (for instance) the same active measurement traff= ic. folloiwng the discussion in the WG meeting. There's a separate entry in the registry for each of these metrics. For the= above requirement, they also need to have the same run-time parameters. basically we want to make sure that the measurement agent knows that the sa= me active traffic can be used to measure all the metrics . even if the MA i= s a simple device. it would be bad news to send separate active measurement= traffic for each metric. The first thing that should help is for the names of the metrics in the reg= istry are sensible. then you get a hint that it may be possible. eg "Act_UD= P_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" The main way is that the Instruction has a single Schedule with several Tas= ks listed in it, ie run these tasks at the same time. In this case, the mos= t likely reason is that several measurements are to be made on the same tra= ffic. The other possibility is that one Task is just creating loading traff= ic and the other Tasks are 'normal' ones. Perhaps we should recommend that = the former should be in a separate Schedule? so that the MA knows for sure. best wishes, phil --_000_143767262744277643btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I was just discussing with Al and Marcelo the issue of when you want to = measure multiple metrics from (for instance) the same active measurement tr= affic. folloiwng the discussion in the WG meeting.

There's a separate entry in the registry for each of these metrics. For = the above requirement, they also need to have the same run-time parameters.=  

 

basically we want to make sure that the measurement agent knows that the= same active traffic can be used to measure all the metrics . even if the M= A is a simple device. it would be bad news to send separate = active measurement traffic for each metric.

 

The first thing that should help is for the names of the metrics i= n the registry are sensible. then you get a hint that it may be possible. e= g "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Pois= son_mean"

 

The main way is that the Instruction has a single Schedule w= ith several Tasks listed in it, ie run these tasks at the same time. In thi= s case, the most likely reason is that several measurements are to be made = on the same traffic. The other possibility is that one Task is just creating loading traffic and the other Tasks are = 'normal' ones. Perhaps we should recommend that the former should be in a s= eparate Schedule? so that the MA knows for sure.

 

best wishes,

phil

--_000_143767262744277643btcom_-- From nobody Thu Jul 23 13:00:01 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8401A00B8 for ; Thu, 23 Jul 2015 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvQe2VapUbq7 for ; Thu, 23 Jul 2015 12:59:57 -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 4DE861A889F for ; Thu, 23 Jul 2015 12:59:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E2A131561; Thu, 23 Jul 2015 21:59:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kM6en-5jK9Gx; Thu, 23 Jul 2015 21:59:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Jul 2015 21:59:25 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 980CF20039; Thu, 23 Jul 2015 21:59:29 +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 B8pNM5SRDZ5K; Thu, 23 Jul 2015 21:59:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C45B82003A; Thu, 23 Jul 2015 21:59:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3244235DEB1E; Thu, 23 Jul 2015 21:59:25 +0200 (CEST) Date: Thu, 23 Jul 2015 21:59:25 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20150723195925.GA10942@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <1437672627442.77643@bt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1437672627442.77643@bt.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 20:00:00 -0000 On Thu, Jul 23, 2015 at 05:30:10PM +0000, philip.eardley@bt.com wrote: > I was just discussing with Al and Marcelo the issue of when you want to measure multiple metrics from (for instance) the same active measurement traffic. folloiwng the discussion in the WG meeting. > > There's a separate entry in the registry for each of these metrics. For the above requirement, they also need to have the same run-time parameters. > > basically we want to make sure that the measurement agent knows that the same active traffic can be used to measure all the metrics . even if the MA is a simple device. it would be bad news to send separate active measurement traffic for each metric. > > The first thing that should help is for the names of the metrics in the registry are sensible. then you get a hint that it may be possible. eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" > > The main way is that the Instruction has a single Schedule with several Tasks listed in it, ie run these tasks at the same time. In this case, the most likely reason is that several measurements are to be made on the same traffic. The other possibility is that one Task is just creating loading traffic and the other Tasks are 'normal' ones. Perhaps we should recommend that the former should be in a separate Schedule? so that the MA knows for sure. > I do not think so. The MA simply kicks of tasks, it does not understand what the tasks do. My understand is that a task actually declares (via references to the registry) which metrics it is going to produce. So if a task points to the two registry entries Act_UDP_Latency_Poisson_mean Act_UDP_Loss_Poisson_mean that it is clear that once you run this task, you will get both metrics. I more or less assume that the number of metrics a task can produce is a more or less static property of a task. Perhaps it would help a lot if there were example metric registry entries somewhere in draft-ietf-ippm-metric-registry-04.txt. The artwork on page 11 kind of leaves me a bit puzzled. I guess the answer is 'read the whole document carefully' but then having easy to understand examples is often helpful... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 23 23:18:30 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605E81ACD08 for ; Thu, 23 Jul 2015 23:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQrj-_7HoNNQ for ; Thu, 23 Jul 2015 23:18:15 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4B9F1B2F57 for ; Thu, 23 Jul 2015 23:18:14 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 0D127120F1E; Fri, 24 Jul 2015 02:41:32 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 61485F03DD; Fri, 24 Jul 2015 02:18:11 -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; Fri, 24 Jul 2015 02:18:11 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Fri, 24 Jul 2015 02:18:09 -0400 Thread-Topic: [lmap] Multiple metrics measured on same active measurement traffic. Thread-Index: AdDFgjOXf3yrCPgOQXaUmYA00kxIWQAVS1QW Message-ID: <4AF73AA205019A4C8A1DDD32C034631D099E186ADD@NJFPSRVEXG0.research.att.com> References: <1437672627442.77643@bt.com>, <20150723195925.GA10942@elstar.local> In-Reply-To: <20150723195925.GA10942@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:18:18 -0000 Hi Juergen, Draft-Morton-IPPM-initial-entries (sorry but that file name has been mangle= d by my keyboard But the file is linked with the related documents on IPPM pages) Has examples, and perhaps the most relevant is the last, section 8 I believ= e. Note that this is an attempt to specify multiple entries with minimum=20 redundant sections. Regards, Al ________________________________________ From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Thursday, July 23, 2015 3:59 PM To: philip.eardley@bt.com Cc: lmap@ietf.org Subject: Re: [lmap] Multiple metrics measured on same active measurement tr= affic. On Thu, Jul 23, 2015 at 05:30:10PM +0000, philip.eardley@bt.com wrote: > I was just discussing with Al and Marcelo the issue of when you want to m= easure multiple metrics from (for instance) the same active measurement tra= ffic. folloiwng the discussion in the WG meeting. > > There's a separate entry in the registry for each of these metrics. For t= he above requirement, they also need to have the same run-time parameters. > > basically we want to make sure that the measurement agent knows that the = same active traffic can be used to measure all the metrics . even if the MA= is a simple device. it would be bad news to send separate active measureme= nt traffic for each metric. > > The first thing that should help is for the names of the metrics in the r= egistry are sensible. then you get a hint that it may be possible. eg "Act_= UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" > > The main way is that the Instruction has a single Schedule with several T= asks listed in it, ie run these tasks at the same time. In this case, the m= ost likely reason is that several measurements are to be made on the same t= raffic. The other possibility is that one Task is just creating loading tra= ffic and the other Tasks are 'normal' ones. Perhaps we should recommend tha= t the former should be in a separate Schedule? so that the MA knows for sur= e. > I do not think so. The MA simply kicks of tasks, it does not understand what the tasks do. My understand is that a task actually declares (via references to the registry) which metrics it is going to produce. So if a task points to the two registry entries Act_UDP_Latency_Poisson_mean Act_UDP_Loss_Poisson_mean that it is clear that once you run this task, you will get both metrics. I more or less assume that the number of metrics a task can produce is a more or less static property of a task. Perhaps it would help a lot if there were example metric registry entries somewhere in draft-ietf-ippm-metric-registry-04.txt. The artwork on page 11 kind of leaves me a bit puzzled. I guess the answer is 'read the whole document carefully' but then having easy to understand examples is often helpful... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From nobody Thu Jul 23 23:37:04 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725361B2F6E for ; Thu, 23 Jul 2015 23:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SOvJ7kQXlUN for ; Thu, 23 Jul 2015 23:36:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 926061A1BC8 for ; Thu, 23 Jul 2015 23:36:59 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 7212B39C5F153; Fri, 24 Jul 2015 06:36:55 +0000 (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 t6O6aukX011284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jul 2015 06:36:56 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 02:36:56 -0400 From: "Carey, Timothy (Timothy)" To: "philip.eardley@bt.com" , "lmap@ietf.org" Thread-Topic: [lmap] Multiple metrics measured on same active measurement traffic. Thread-Index: AQHQxXn86D0g895Tk0CsqiEllj5Mg53qKr/w Date: Fri, 24 Jul 2015 06:36:54 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2243E0@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <1437672627442.77643@bt.com> In-Reply-To: <1437672627442.77643@bt.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_9966516C6EB5FC4381E05BF80AA55F77DC2243E0US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:37:02 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC2243E0US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I guess I don't understand the context of the comment. Was the context of t= he comment from the f2f meeting's discussion of multiple task registry entr= ies for a task - were we said multiple metrics (task registry entries) can = be assigned to a task which is then scheduled? BR, Tim From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Thursday, July 23, 2015 7:30 PM To: lmap@ietf.org Subject: [lmap] Multiple metrics measured on same active measurement traffi= c. I was just discussing with Al and Marcelo the issue of when you want to mea= sure multiple metrics from (for instance) the same active measurement traff= ic. folloiwng the discussion in the WG meeting. There's a separate entry in the registry for each of these metrics. For the= above requirement, they also need to have the same run-time parameters. basically we want to make sure that the measurement agent knows that the sa= me active traffic can be used to measure all the metrics . even if the MA i= s a simple device. it would be bad news to send separate active measurement= traffic for each metric. The first thing that should help is for the names of the metrics in the reg= istry are sensible. then you get a hint that it may be possible. eg "Act_UD= P_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" The main way is that the Instruction has a single Schedule with several Tas= ks listed in it, ie run these tasks at the same time. In this case, the mos= t likely reason is that several measurements are to be made on the same tra= ffic. The other possibility is that one Task is just creating loading traff= ic and the other Tasks are 'normal' ones. Perhaps we should recommend that = the former should be in a separate Schedule? so that the MA knows for sure. best wishes, phil --_000_9966516C6EB5FC4381E05BF80AA55F77DC2243E0US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,

 

I guess I don’= t understand the context of the comment. Was the context of the comment fro= m the f2f meeting’s discussion of multiple task registry entries for a task – were we said multiple metrics (task registry entries) c= an be assigned to a task which is then scheduled?

 

BR,

Tim

 

From: philip.e= ardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Thursday, July 23, 2015 7:30 PM
To: lmap@ietf.org
Subject: [lmap] Multiple metrics measured on same active measurement= traffic.

 

I was just discussing with Al and Marcelo the issue of when you = want to measure multiple metrics from (for instance) the same active measur= ement traffic. folloiwng the discussion in the WG meeting.

There's a separate entry in the registry for each of these metri= cs. For the above requirement, they also need to have the same run-time par= ameters. 

 

basically we want to make sure that the measurement agent knows = that the same active traffic can be used to measure all the metrics . even = if the MA is a simple device. it would be bad news to send separate active measurement traffic for each metric. =

 

The first thing that should help is for the names of the metrics= in the registry are sensible. then you get a hint that it may be possible.= eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson= _mean"

 

The main way is that the Instruction has a single Schedule with = several Tasks listed in it, ie run these tasks at the same time. In this ca= se, the most likely reason is that several measurements are to be made on the same traffic. The other possibility is that one Task= is just creating loading traffic and the other Tasks are 'normal' ones. Pe= rhaps we should recommend that the former should be in a separate Schedule?= so that the MA knows for sure.

 

best wishes,

phil

--_000_9966516C6EB5FC4381E05BF80AA55F77DC2243E0US70UWXCHMBA05z_-- From nobody Thu Jul 23 23:39:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB011A871B for ; Thu, 23 Jul 2015 23:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDcDxzrj0iE2 for ; Thu, 23 Jul 2015 23:39:15 -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 543A31B2F65 for ; Thu, 23 Jul 2015 23:39:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A492A10B3; Fri, 24 Jul 2015 08:39:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 62IL9s9qUzaV; Fri, 24 Jul 2015 08:39:08 +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, 24 Jul 2015 08:39:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14D8A2003A; Fri, 24 Jul 2015 08:39:12 +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 at3D7EUzqsGX; Fri, 24 Jul 2015 08:39:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AC2020039; Fri, 24 Jul 2015 08:39:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A60CD35DEE5E; Fri, 24 Jul 2015 08:39:08 +0200 (CEST) Date: Fri, 24 Jul 2015 08:39:07 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20150724063905.GA12023@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20150723195925.GA10942@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D099E186ADD@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D099E186ADD@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 06:39:18 -0000 Hi Al, thanks for this pointer. I would have loved if there would have been something structured machine readable but it perhaps IANA creates this somehow. Looking at section 8, I already have the question whether LMAP should refer to the URN or the URI. Is there any recommendation that we should make? /js PS: I wonder whether the capitalization rules for names not make things more complex than needed - but then perhaps the names are too hard to type anyway. On Fri, Jul 24, 2015 at 02:18:09AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > Draft-Morton-IPPM-initial-entries (sorry but that file name has been mangled by my keyboard > But the file is linked with the related documents on IPPM pages) > > Has examples, and perhaps the most relevant is the last, section 8 I believe. > Note that this is an attempt to specify multiple entries with minimum > redundant sections. > > Regards, > Al > ________________________________________ > From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 23, 2015 3:59 PM > To: philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. > > On Thu, Jul 23, 2015 at 05:30:10PM +0000, philip.eardley@bt.com wrote: > > I was just discussing with Al and Marcelo the issue of when you want to measure multiple metrics from (for instance) the same active measurement traffic. folloiwng the discussion in the WG meeting. > > > > There's a separate entry in the registry for each of these metrics. For the above requirement, they also need to have the same run-time parameters. > > > > basically we want to make sure that the measurement agent knows that the same active traffic can be used to measure all the metrics . even if the MA is a simple device. it would be bad news to send separate active measurement traffic for each metric. > > > > The first thing that should help is for the names of the metrics in the registry are sensible. then you get a hint that it may be possible. eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" > > > > The main way is that the Instruction has a single Schedule with several Tasks listed in it, ie run these tasks at the same time. In this case, the most likely reason is that several measurements are to be made on the same traffic. The other possibility is that one Task is just creating loading traffic and the other Tasks are 'normal' ones. Perhaps we should recommend that the former should be in a separate Schedule? so that the MA knows for sure. > > > > I do not think so. The MA simply kicks of tasks, it does not > understand what the tasks do. My understand is that a task actually > declares (via references to the registry) which metrics it is going to > produce. So if a task points to the two registry entries > > Act_UDP_Latency_Poisson_mean > Act_UDP_Loss_Poisson_mean > > that it is clear that once you run this task, you will get both > metrics. I more or less assume that the number of metrics a task can > produce is a more or less static property of a task. > > Perhaps it would help a lot if there were example metric registry > entries somewhere in draft-ietf-ippm-metric-registry-04.txt. The > artwork on page 11 kind of leaves me a bit puzzled. I guess the answer > is 'read the whole document carefully' but then having easy to > understand examples is often helpful... > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- 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 Jul 24 00:41:47 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFC81ACEC6 for ; Fri, 24 Jul 2015 00:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enx_v-OJHOSV for ; Fri, 24 Jul 2015 00:41:44 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AEAE1B2FBD for ; Fri, 24 Jul 2015 00:41:43 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 24 Jul 2015 08:41:38 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 24 Jul 2015 08:41:41 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 24 Jul 2015 08:41:40 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.0995.031; Fri, 24 Jul 2015 08:41:40 +0100 From: To: , Thread-Topic: Multiple metrics measured on same active measurement traffic. Thread-Index: AQHQxW0eVNepC19p7UKtN/k0Qzp2a53qPSPA Date: Fri, 24 Jul 2015 07:41:39 +0000 Message-ID: <59aeffdb44cf4a89a34e587aefca5f98@rew09926dag03c.domain1.systemhost.net> References: <1437672627442.77643@bt.com> In-Reply-To: <1437672627442.77643@bt.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_59aeffdb44cf4a89a34e587aefca5f98rew09926dag03cdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 07:41:46 -0000 --_000_59aeffdb44cf4a89a34e587aefca5f98rew09926dag03cdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a slight correction here: if you want multiple tasks to run simultaneo= usly then you create parallel schedules with the same execution time. If mu= ltiple tasks are within a single schedule they will run in sequence. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.co= m Sent: 23 July 2015 18:30 To: lmap@ietf.org Subject: [lmap] Multiple metrics measured on same active measurement traffi= c. I was just discussing with Al and Marcelo the issue of when you want to mea= sure multiple metrics from (for instance) the same active measurement traff= ic. folloiwng the discussion in the WG meeting. There's a separate entry in the registry for each of these metrics. For the= above requirement, they also need to have the same run-time parameters. basically we want to make sure that the measurement agent knows that the sa= me active traffic can be used to measure all the metrics . even if the MA i= s a simple device. it would be bad news to send separate active measurement= traffic for each metric. The first thing that should help is for the names of the metrics in the reg= istry are sensible. then you get a hint that it may be possible. eg "Act_UD= P_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" The main way is that the Instruction has a single Schedule with several Tas= ks listed in it, ie run these tasks at the same time. In this case, the mos= t likely reason is that several measurements are to be made on the same tra= ffic. The other possibility is that one Task is just creating loading traff= ic and the other Tasks are 'normal' ones. Perhaps we should recommend that = the former should be in a separate Schedule? so that the MA knows for sure. best wishes, phil --_000_59aeffdb44cf4a89a34e587aefca5f98rew09926dag03cdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a sli= ght correction here: if you want multiple tasks to run simultaneously then = you create parallel schedules with the same execution time. If multiple tasks are within a single schedule they will run in sequ= ence.

 = ;

Trevor.

 = ;

From: = lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 23 July 2015 18:30
To: lmap@ietf.org
Subject: [lmap] Multiple metrics measured on same active measurement= traffic.

 

I= was just discussing with Al and Marcelo the issue of when you want to meas= ure multiple metrics from (for instance) the same active measurement traffi= c. folloiwng the discussion in the WG meeting.

T= here's a separate entry in the registry for each of these metrics. For the = above requirement, they also need to have the same run-time parameters.&nbs= p;

&= nbsp;

b= asically we want to make sure that the measurement agent knows that the sam= e active traffic can be used to measure all the metrics . even if the MA is= a simple device. it would be bad news to send separate active measurement traffic for each metric.

&= nbsp;

T= he first thing that should help is for the names of the metrics in the regi= stry are sensible. then you get a hint that it may be possible. eg "Ac= t_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean"<= o:p>

&= nbsp;

T= he main way is that the Instruction has a single Schedule with several Task= s listed in it, ie run these tasks at the same time. In this case, the most= likely reason is that several measurements are to be made on the same traffic. The other possibility is that one Task= is just creating loading traffic and the other Tasks are 'normal' ones. Pe= rhaps we should recommend that the former should be in a separate Schedule?= so that the MA knows for sure.

&= nbsp;

b= est wishes,

p= hil

--_000_59aeffdb44cf4a89a34e587aefca5f98rew09926dag03cdomain1sy_-- From nobody Fri Jul 24 02:28:43 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A761A8894 for ; Fri, 24 Jul 2015 02:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_CR5DTUA58v for ; Fri, 24 Jul 2015 02:28:40 -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 E6B781A8821 for ; Fri, 24 Jul 2015 02:28:39 -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 75940120D5C; Fri, 24 Jul 2015 05:51:57 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 06160E034B; Fri, 24 Jul 2015 05:27:36 -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; Fri, 24 Jul 2015 05:28:36 -0400 From: "MORTON, ALFRED C (AL)" To: Juergen Schoenwaelder Date: Fri, 24 Jul 2015 05:28:33 -0400 Thread-Topic: [lmap] Multiple metrics measured on same active measurement traffic. Thread-Index: AdDF23xLyX50VFSOTQCikPGCEs9v2gAFtBAg Message-ID: <4AF73AA205019A4C8A1DDD32C034631D099E089FEE@NJFPSRVEXG0.research.att.com> References: <20150723195925.GA10942@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D099E186ADD@NJFPSRVEXG0.research.att.com> <20150724063905.GA12023@elstar.local> In-Reply-To: <20150724063905.GA12023@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:28:42 -0000 Hi Juergen, The "machine-readable" view was also the subject of one of Barbara Stark's reviews of the registry, and discussed at the last IPPM session. Our view has been that this is a registry for implementers to read, and that they are likely to be humans. Personally, I think the URL will be more useful to humans and the=20 URI for a wider audience. But maybe I don't understand yet the full implications of those assignments. regards, Al > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, July 24, 2015 2:39 AM > To: MORTON, ALFRED C (AL) > Cc: philip.eardley@bt.com; lmap@ietf.org > Subject: Re: [lmap] Multiple metrics measured on same active measurement > traffic. >=20 > Hi Al, >=20 > thanks for this pointer. I would have loved if there would have been > something structured machine readable but it perhaps IANA creates this > somehow. Looking at section 8, I already have the question whether LMAP > should refer to the URN or the URI. Is there any recommendation that we > should make? >=20 > /js >=20 > PS: I wonder whether the capitalization rules for names not make > things more complex than needed - but then perhaps the names are > too hard to type anyway. >=20 > On Fri, Jul 24, 2015 at 02:18:09AM -0400, MORTON, ALFRED C (AL) wrote: > > Hi Juergen, > > > > Draft-Morton-IPPM-initial-entries (sorry but that file name has been > > mangled by my keyboard But the file is linked with the related > > documents on IPPM pages) > > > > Has examples, and perhaps the most relevant is the last, section 8 I > believe. > > Note that this is an attempt to specify multiple entries with minimum > > redundant sections. > > > > Regards, > > Al > > ________________________________________ > > From: lmap [lmap-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > [j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, July 23, 2015 3:59 PM > > To: philip.eardley@bt.com > > Cc: lmap@ietf.org > > Subject: Re: [lmap] Multiple metrics measured on same active > measurement traffic. > > > > On Thu, Jul 23, 2015 at 05:30:10PM +0000, philip.eardley@bt.com wrote: > > > I was just discussing with Al and Marcelo the issue of when you want > to measure multiple metrics from (for instance) the same active > measurement traffic. folloiwng the discussion in the WG meeting. > > > > > > There's a separate entry in the registry for each of these metrics. > For the above requirement, they also need to have the same run-time > parameters. > > > > > > basically we want to make sure that the measurement agent knows that > the same active traffic can be used to measure all the metrics . even if > the MA is a simple device. it would be bad news to send separate active > measurement traffic for each metric. > > > > > > The first thing that should help is for the names of the metrics in > the registry are sensible. then you get a hint that it may be possible. > eg "Act_UDP_Latency_Poisson_mean" and "Act_UDP_Loss_Poisson_mean" > > > > > > The main way is that the Instruction has a single Schedule with > several Tasks listed in it, ie run these tasks at the same time. In this > case, the most likely reason is that several measurements are to be made > on the same traffic. The other possibility is that one Task is just > creating loading traffic and the other Tasks are 'normal' ones. Perhaps > we should recommend that the former should be in a separate Schedule? so > that the MA knows for sure. > > > > > > > I do not think so. The MA simply kicks of tasks, it does not > > understand what the tasks do. My understand is that a task actually > > declares (via references to the registry) which metrics it is going to > > produce. So if a task points to the two registry entries > > > > Act_UDP_Latency_Poisson_mean > > Act_UDP_Loss_Poisson_mean > > > > that it is clear that once you run this task, you will get both > > metrics. I more or less assume that the number of metrics a task can > > produce is a more or less static property of a task. > > > > Perhaps it would help a lot if there were example metric registry > > entries somewhere in draft-ietf-ippm-metric-registry-04.txt. The > > artwork on page 11 kind of leaves me a bit puzzled. I guess the answer > > is 'read the whole document carefully' but then having easy to > > understand examples is often helpful... > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Jul 24 02:34:03 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A91A8860 for ; Fri, 24 Jul 2015 02:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkPIsS3r9Bse for ; Fri, 24 Jul 2015 02:33:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933921A6FEE for ; Fri, 24 Jul 2015 02:33:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE06C13F3; Fri, 24 Jul 2015 11:33:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZGdKuGTZDbG1; Fri, 24 Jul 2015 11:33:44 +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, 24 Jul 2015 11:33:44 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BB0A2003A; Fri, 24 Jul 2015 11:33:48 +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 RfPmjk_i2F8N; Fri, 24 Jul 2015 11:34:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62DA520039; Fri, 24 Jul 2015 11:33:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 795F435DF3CA; Fri, 24 Jul 2015 11:33:45 +0200 (CEST) Date: Fri, 24 Jul 2015 11:33:45 +0200 From: Juergen Schoenwaelder To: "MORTON, ALFRED C (AL)" Message-ID: <20150724093343.GB12554@elstar.local> Mail-Followup-To: "MORTON, ALFRED C (AL)" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <20150723195925.GA10942@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D099E186ADD@NJFPSRVEXG0.research.att.com> <20150724063905.GA12023@elstar.local> <4AF73AA205019A4C8A1DDD32C034631D099E089FEE@NJFPSRVEXG0.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D099E089FEE@NJFPSRVEXG0.research.att.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Multiple metrics measured on same active measurement traffic. X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:34:01 -0000 On Fri, Jul 24, 2015 at 05:28:33AM -0400, MORTON, ALFRED C (AL) wrote: > Hi Juergen, > > The "machine-readable" view was also the subject of one of Barbara > Stark's reviews of the registry, and discussed at the last IPPM session. > Our view has been that this is a registry for implementers to read, > and that they are likely to be humans. Hm. Given the fine granularity of the metric definitions, I expect a number of metrics that likely asks for tools. IANA anyway seems to prefer to store all registry data in XML format (or something that exports into an XML format). Did you talk to IANA how they like to maintain this? > Personally, I think the URL will be more useful to humans and the > URI for a wider audience. But maybe I don't understand yet the > full implications of those assignments. For tools, having multiple identifiers for the same thing makes life more complex. You (IPPM) seem to have plenty of identifiers for the same thing. /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 Jul 27 11:49:02 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DFF1B321E for ; Mon, 27 Jul 2015 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSE55DhlzpZ3 for ; Mon, 27 Jul 2015 11:48:57 -0700 (PDT) Received: from worker1.doodle.com (worker1.doodle.com [94.230.219.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0DD1B31F2 for ; Mon, 27 Jul 2015 11:48:57 -0700 (PDT) Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id 5D5D3104E1C4 for ; Mon, 27 Jul 2015 20:48:55 +0200 (CEST) Date: Mon, 27 Jul 2015 20:48:55 +0200 (CEST) From: "Dan Romascanu (via Doodle)" To: Message-ID: <1002128302.1694325.1438022935379.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker1.doodle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1694324_1212801836.1438022935379" Archived-At: Subject: [lmap] LMAP Virtual Interim Meeting X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Dan Romascanu List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 18:49:00 -0000 ------=_Part_1694324_1212801836.1438022935379 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, Dan Romascanu (dromasca@avaya.com) invites you to participate in the Doodle poll "LMAP Virtual Interim Meeting." As discussed at IETF 93, the LMAP WG will hold one interim meeting in the weeks or 9/28 or 10/5, 2015.=20 =20 Please express you preferences and availability by voting in the poll. All times are expressed in US Eastern Time Participate now https://doodle.com/wn5wia9neauecsdc?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/features?tlink=3DcheckOutLink&tmail=3Dpoll_invitecontac= t_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Dan Romascanu" has invited you to participate in the Doodle poll "LMAP Virtual Interim Meeting." ---- Doodle is also available for iOS and Android. ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_1694324_1212801836.1438022935379 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =
=09
Dan Romascanu invites you t= o participate in the Doodle poll "LMAP Virtual Interim Meeting."<= /div> =09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"LMAP Virtual= Interim Meeting." =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09As discussed at IETF 93, the LMAP WG will hold one int= erim meeting in the weeks or 9/28 or 10/5, 2015.

Please express y= ou preferences and availability by voting in the poll. All times are expres= sed in US Eastern Time =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Dan Romascanu to find a suitable date= for meeting with a group of people. Learn more about how Doodle works.
=09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09You have received this e-mail because "Dan Romascanu&= quot; has invited you to participate in the Doodle poll "LMAP Virtual = Interim Meeting." =09=09
=09
Doodle is also available for iOS and Android.
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_1694324_1212801836.1438022935379-- From nobody Mon Jul 27 12:20:11 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF111B32C2 for ; Mon, 27 Jul 2015 12:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTEcDXQjimXA for ; Mon, 27 Jul 2015 12:20:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 01EAA1B32A3 for ; Mon, 27 Jul 2015 12:20:09 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 99A10BA5A9A78 for ; Mon, 27 Jul 2015 19:20:03 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t6RJK6wj020498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jul 2015 19:20:06 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 15:20:06 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout Thread-Index: AdDIoT1fxEvI3zkiRMmSUQt9jimZMQ== Date: Mon, 27 Jul 2015 19:20:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC22667FUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:20:11 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22667FUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I was updating the TR-069 model and still have some questions about the dis= abling of schedules. What happens if I disable a schedule but the schedule references an action = that is MA communication specific AND say an instruction? It really sounds like we are disabling actions not schedules... It certainl= y would be much easier. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC22667FUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I was updating the TR-069 model and still have some= questions about the disabling of schedules.

 

What happens if I disable a schedule but the schedu= le references an action that is MA communication specific AND say an instru= ction?

 

It really sounds like we are disabling actions not = schedules… It certainly would be much easier.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22667FUS70UWXCHMBA05z_-- From nobody Mon Jul 27 12:29:55 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC11B30AD for ; Mon, 27 Jul 2015 12:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DzMdu52o1zT for ; Mon, 27 Jul 2015 12:29:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 9024F1B3127 for ; Mon, 27 Jul 2015 12:29:51 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id ECE3F954A1627 for ; Mon, 27 Jul 2015 19:29:45 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t6RJTm3u002368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jul 2015 19:29:48 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 15:29:48 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions Thread-Index: AdDIopjZyz/Kw0xSTYWzPqJYAgTc7Q== Date: Mon, 27 Jul 2015 19:29:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC226694@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC226694US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Action Execution Mode questions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:29:53 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC226694US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In reviewing this draft for the TR-069 model update I had a question on the= Execution mode. We say there are 3 modes - Sequential, Parallel and Pipelined. For sequential - What is the value that orders the list? I don't see an ord= ering the action or indication that this is an ordered list of actions. For pipelining - I don't understand this mode - are we saying that this is = a Sequential mode plus all the outputs for executing Action are inputted to= the next Action in the Sequence or is the Pipeline mode somehow relevant f= or Output destinations? If so why wouldn't pipeline simply be sequential or= paralled with output destinations? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC226694US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In reviewing this draft for the TR-069 model update= I had a question on the Execution mode.

We say there are 3 modes – Sequential, Parall= el and Pipelined.

For sequential – What is the value that order= s the list? I don’t see an ordering the action or indication that thi= s is an ordered list of actions.

 

For pipelining – I don’t understand thi= s mode – are we saying that this is a Sequential mode plus all the ou= tputs for executing Action are inputted to the next Action in the Sequence or is the Pipeline mode somehow relevant for Output destinations? If so wh= y wouldn’t pipeline simply be sequential or paralled with output dest= inations?

 

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC226694US70UWXCHMBA05z_-- From nobody Mon Jul 27 12:41:18 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CAE1B3315 for ; Mon, 27 Jul 2015 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgg3wxY9rKBO for ; Mon, 27 Jul 2015 12:41:15 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 BD9AA1B3310 for ; Mon, 27 Jul 2015 12:41:14 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 48FAE6B4D8BA6 for ; Mon, 27 Jul 2015 19:41:09 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t6RJfBfU020005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jul 2015 19:41:11 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 15:41:11 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Actions Thread-Index: AdDIpDAWU2XEzjayR2GMQqprCIoi+w== Date: Mon, 27 Jul 2015 19:41:10 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2266C0@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC2266C0US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: Actions X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 19:41:16 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC2266C0US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, If Actions are now considered stand-alone entities outside the schedule. Sh= ouldn't the MA have a list of Actions available like Tasks and Communicatio= nChannels? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC2266C0US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

If Actions are now considered stand-alone entities = outside the schedule. Shouldn’t the MA have a list of Actions availab= le like Tasks and CommunicationChannels?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC2266C0US70UWXCHMBA05z_-- From nobody Mon Jul 27 13:23:09 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1879F1B337E for ; Mon, 27 Jul 2015 13:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvCcegYEqjjo for ; Mon, 27 Jul 2015 13:23:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 000831B3312 for ; Mon, 27 Jul 2015 13:23:05 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id CAD099DDFEFD9 for ; Mon, 27 Jul 2015 20:22:59 +0000 (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 t6RKN2rB006095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jul 2015 20:23:02 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 16:23:02 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06 Thread-Index: AdDIqgiw+r133pijTKmFc1E3lUc0ag== Date: Mon, 27 Jul 2015 20:23:01 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC226710@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC226710US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: draft-ietf-lmap-information-model-06 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 20:23:08 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC226710US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, I was looking at the definition of ma-action-destinations. I don't understa= nd what we did here. It used to be the case that a registry entry can define outputs that were p= ipelined to a scheduled action. Now I it looks like it is a schedule. However previously we said: An empty list means that all outputs defined by the Action's task registry = are invoked. - this is missing from you draft - what do we do with an empty= list? Likewise we actually defined the output number to a list of Schedules - I d= idn't see that modeled in the simple list of schedules. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC226710US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

I was looking at the definition of ma-action-destina= tions. I don’t understand what we did here.

 

It used to be the case that a registry entry can def= ine outputs that were pipelined to a scheduled action. Now I it looks like = it is a schedule.

 

However previously we said:

An empty list means that all outputs defined by the Action's task registry= are invoked. – this is missing from you draft – what do= we do with an empty list?

 

Likewise we actually defined the output number to a = list of Schedules – I didn’t see that modeled in the simple lis= t of schedules.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC226710US70UWXCHMBA05z_-- From nobody Mon Jul 27 13:46:20 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A671B33C4 for ; Mon, 27 Jul 2015 13:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZCH4pIBbGOb for ; Mon, 27 Jul 2015 13:46:17 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 44AA91B33C3 for ; Mon, 27 Jul 2015 13:46:16 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 407A6AAA27980 for ; Mon, 27 Jul 2015 20:46:11 +0000 (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 t6RKkDOs006966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Jul 2015 20:46:13 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 16:46:13 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Instructions and measurement suppression Thread-Index: AdDIrUW2OioeBqBFQTyN/EcXtbqaCA== Date: Mon, 27 Jul 2015 20:46:12 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC226720@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC226720US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: Instructions and measurement suppression X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 20:46:18 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC226720US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In IETF93 you asked if instruction object had any meaning. Well they are used to hold measurement suppression. So if we remove the Ins= truction object we need a place to hold the instructions measurement suppre= ssion. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC226720US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In IETF93 you asked if instruction object had any m= eaning.

Well they are used to hold measurement suppression.= So if we remove the Instruction object we need a place to hold the instruc= tions measurement suppression.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC226720US70UWXCHMBA05z_-- From nobody Tue Jul 28 00:36:58 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACA1A700D for ; Tue, 28 Jul 2015 00:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzZs0nxIA_hg for ; Tue, 28 Jul 2015 00:36:54 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF8F1A3BA0 for ; Tue, 28 Jul 2015 00:36:53 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Jul 2015 08:36:50 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 28 Jul 2015 08:36:51 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Jul 2015 08:36:50 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.0995.031; Tue, 28 Jul 2015 08:36:50 +0100 From: To: , Thread-Topic: Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout Thread-Index: AdDIoT1fxEvI3zkiRMmSUQt9jimZMQAZr7wQ Date: Tue, 28 Jul 2015 07:36:50 +0000 Message-ID: <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> References: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: multipart/alternative; boundary="_000_244dbae6d49b4142a441f0e5534d9b56rew09926dag03cdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 07:36:57 -0000 --_000_244dbae6d49b4142a441f0e5534d9b56rew09926dag03cdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this isn't possible. The Control and Instruction schedules are held= separately and the Control schedules cannot be suppressed. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 27 July 2015 20:20 To: lmap@ietf.org Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling s= chedules on controller timeout Juergen, I was updating the TR-069 model and still have some questions about the dis= abling of schedules. What happens if I disable a schedule but the schedule references an action = that is MA communication specific AND say an instruction? It really sounds like we are disabling actions not schedules... It certainl= y would be much easier. BR, Tim --_000_244dbae6d49b4142a441f0e5534d9b56rew09926dag03cdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think this isn’t possible. The Control and Instruction schedul= es are held separately and the Control schedules cannot be suppressed.=

 

Trevor.

 

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 27 July 2015 20:20
To: lmap@ietf.org
Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disa= bling schedules on controller timeout

 

Juergen,

 

I was updating the TR-069 model and still have s= ome questions about the disabling of schedules.

 

What happens if I disable a schedule but the sch= edule references an action that is MA communication specific AND say an ins= truction?

 

It really sounds like we are disabling actions n= ot schedules… It certainly would be much easier.

 

BR,

Tim

--_000_244dbae6d49b4142a441f0e5534d9b56rew09926dag03cdomain1sy_-- From nobody Tue Jul 28 04:50:56 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596F51A89B0 for ; Tue, 28 Jul 2015 04:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHB2GUAAlx7z for ; Tue, 28 Jul 2015 04:50:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 5AF2C1A8954 for ; Tue, 28 Jul 2015 04:50:46 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 5A0F1FEDEC526; Tue, 28 Jul 2015 11:50:41 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t6SBogJB012066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jul 2015 11:50:42 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 07:50:41 -0400 From: "Carey, Timothy (Timothy)" To: "trevor.burbridge@bt.com" , "lmap@ietf.org" Thread-Topic: Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout Thread-Index: AdDIoT1fxEvI3zkiRMmSUQt9jimZMQAZr7wQAAjiN+A= Date: Tue, 28 Jul 2015 11:50:41 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC227066@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC22667F@US70UWXCHMBA05.zam.alcatel-lucent.com> <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> In-Reply-To: <244dbae6d49b4142a441f0e5534d9b56@rew09926dag03c.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC227066US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling schedules on controller timeout X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 11:50:54 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC227066US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well maybe we should then indicate a schedule as control or instruction and= then say only instruction schedules are autonomously disabled and enabled? From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com] Sent: Tuesday, July 28, 2015 2:37 AM To: Carey, Timothy (Timothy); lmap@ietf.org Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabling sche= dules on controller timeout I think this isn't possible. The Control and Instruction schedules are held= separately and the Control schedules cannot be suppressed. Trevor. From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timo= thy) Sent: 27 July 2015 20:20 To: lmap@ietf.org Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disabling s= chedules on controller timeout Juergen, I was updating the TR-069 model and still have some questions about the dis= abling of schedules. What happens if I disable a schedule but the schedule references an action = that is MA communication specific AND say an instruction? It really sounds like we are disabling actions not schedules... It certainl= y would be much easier. BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC227066US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well maybe we should then indicate a = schedule as control or instruction and then say only instruction schedules = are autonomously disabled and enabled?

 

From: trevor.b= urbridge@bt.com [mailto:trevor.burbridge@bt.com]
Sent: Tuesday, July 28, 2015 2:37 AM
To: Carey, Timothy (Timothy); lmap@ietf.org
Subject: RE: Review of draft-ietf-lmap-information-model-06: Disabli= ng schedules on controller timeout

 

I think= this isn’t possible. The Control and Instruction schedules are held = separately and the Control schedules cannot be suppressed.

&n= bsp;

Trevor.=

&n= bsp;

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Carey, Timothy (Timothy)
Sent: 27 July 2015 20:20
To: lmap@ietf.org
Subject: [lmap] Review of draft-ietf-lmap-information-model-06: Disa= bling schedules on controller timeout

 

Juergen,

 

I was updating the TR-069 model and still have some= questions about the disabling of schedules.

 

What happens if I disable a schedule but the schedu= le references an action that is MA communication specific AND say an instru= ction?

 

It really sounds like we are disabling actions not = schedules… It certainly would be much easier.

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC227066US70UWXCHMBA05z_-- From nobody Tue Jul 28 07:53:00 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3CA1AC413 for ; Tue, 28 Jul 2015 07:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNpKOQ6VJLOo for ; Tue, 28 Jul 2015 07:52:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 0B1111AC3AB for ; Tue, 28 Jul 2015 07:52:57 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2AB3A9F07516F for ; Tue, 28 Jul 2015 14:52:52 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t6SEqrVH012844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 14:52:53 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 10:52:53 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model Thread-Index: AdDJRJl94Hgt5QTGRLCN+LS+Jyv9tg== Date: Tue, 28 Jul 2015 14:52:53 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC227456@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_9966516C6EB5FC4381E05BF80AA55F77DC227456US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: Reinsert Task Capabilities and ma conditions back into the information model X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:52:58 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC227456US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In draft 05 we removed the ability for a measurement agent to report its me= trics that it supports. We need to add * ma-task-capability-obj ma-supported-tasks<0..*>; * [ma-condition-obj ma-conditions<0..*>;] They were in the ma-status-obj. --_000_9966516C6EB5FC4381E05BF80AA55F77DC227456US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

In draft 05 we removed the ability for a measuremen= t agent to report its metrics that it supports.

We need to add

·         ma-task-capability-obj  ma-supported-t= asks<0..*>;

·         [ma-condition-obj    &n= bsp;   ma-conditions<0..*>;]

 

They were in the ma-status-obj.

--_000_9966516C6EB5FC4381E05BF80AA55F77DC227456US70UWXCHMBA05z_-- From nobody Tue Jul 28 07:53:06 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5352D1AC413 for ; Tue, 28 Jul 2015 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqsomWwZEoca for ; Tue, 28 Jul 2015 07:52:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 CFF7B1AC3EE for ; Tue, 28 Jul 2015 07:52:57 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 37F31C5D633DC for ; Tue, 28 Jul 2015 14:52:54 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t6SEqsTY025616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 14:52:54 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 10:52:54 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Task status object Thread-Index: AdDJRQeckwPfXIUiS+mGVFuobOgxDA== Date: Tue, 28 Jul 2015 14:52:53 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22745E@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_9966516C6EB5FC4381E05BF80AA55F77DC22745EUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: Task status object X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:52:59 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22745EUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, In the ma-task-status object you have multiple role with a single registry = entry for a task. Your description in ma-task-status-obj doesn't seem to ad= d up. What if we have a task with multiple metrics (registry entries)? You also have a list of roles - but a registry entry would only be executed= under 1 role. What is the unique functional key of a task status object now - Task Name, = RegistryEntry, Role? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC22745EUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

 

In the ma-task-status object you have multiple role= with a single registry entry for a task. Your description in ma-task-statu= s-obj doesn’t seem to add up.

 

What if we have a task with multiple metrics (regis= try entries)?

 

You also have a list of roles – but a registr= y entry would only be executed under 1 role.

 

 

What is the unique functional key of a task status = object now – Task Name, RegistryEntry, Role?

 

BR,

Tim

 

 

 

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22745EUS70UWXCHMBA05z_-- From nobody Tue Jul 28 08:58:39 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3F1ACD68 for ; Tue, 28 Jul 2015 08:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbrYF8G3jlt1 for ; Tue, 28 Jul 2015 08:58:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EA74F1ACD61 for ; Tue, 28 Jul 2015 08:57:51 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 821D5AA82EE58 for ; Tue, 28 Jul 2015 15:57:46 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t6SFvmQG028048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 15:57:48 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 11:57:48 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: Report - Task problems Thread-Index: AdDJTiWlq6CgRjNjQa2l4WuYorZC5w== Date: Tue, 28 Jul 2015 15:57:47 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2276A6@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_9966516C6EB5FC4381E05BF80AA55F77DC2276A6US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: Report - Task problems X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 15:58:32 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC2276A6US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, 1) In the ma-report-task-obj, you have the [ma-option-obj ma-repor= t-scheduled-task-options<0..*>]. So do we mean options for MA, the Action o= r the Task? I think we mean the Task here. We also need Action conditions f= or the report right? 2) Use of Registry entry in the Report task; Is this really for a metric= (RegistryEntry) in the task (probably); what about Role of the metric; do = we report on each role/registryentry for the task? (probably) . BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC2276A6US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

1)    In the ma-report-task-obj, you have the [ma= -option-obj       ma-report-scheduled-task-op= tions<0..*>]. So do we mean options for MA, the Action or the Task? I= think we mean the Task here. We also need Action conditions for the report right?

2)    Use of Registry entry in the Report task; I= s this really for a metric (RegistryEntry) in the task (probably); what abo= ut Role of the metric; do we report on each role/registryentry for the task? (probably) .

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC2276A6US70UWXCHMBA05z_-- From nobody Tue Jul 28 11:08:38 2015 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CA11B2CF9 for ; Tue, 28 Jul 2015 11:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnRrde4oUcn5 for ; Tue, 28 Jul 2015 11:08:36 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 EEED21B2D20 for ; Tue, 28 Jul 2015 11:08:09 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 7E946A4EB131B for ; Tue, 28 Jul 2015 18:08:04 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t6SI867T028002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 18:08:06 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 14:08:06 -0400 From: "Carey, Timothy (Timothy)" To: "lmap@ietf.org" Thread-Topic: draft-ietf-lmap-information-model-06: New additions for Schedule Object Thread-Index: AdDJYFlq3tM0y3QZSgSEd/aa1KX54Q== Date: Tue, 28 Jul 2015 18:08:04 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC22793D@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_9966516C6EB5FC4381E05BF80AA55F77DC22793DUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [lmap] draft-ietf-lmap-information-model-06: New additions for Schedule Object X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 18:08:38 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC22793DUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Juergen, To help with the controller timeout, I added an indicator to the schedule i= n TR-069 that shows if the Schedule should be used for MA Control actions. = Likewise I added a status parameter to tell if the Schedule is currently op= erationally disabled. Do you think we can add these to the information model? Status string - The current operational state of the Schedule. Enumeration of: * Enabled * Disabled-MA-ControllerTimout * Disabled-Other * Error (OPTIONAL) The Error value MAY be used by the CPE to indicate a locally defined error = condition. UseForMAControl boolean W This parameter defines if the Schedule is to be used for Actions that speci= fic to the BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC22793DUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen,

 

To help with the controller timeout, I added an ind= icator to the schedule in TR-069 that shows if the Schedule should be used = for MA Control actions. Likewise I added a status parameter to tell if the Schedule is currently operationally disabled.

 

Do you think we can add these to the information mo= del?

 

Status

string

-

The current operational state of the Schedule. Enume= ration of:

  • Enabled
    • Disabled-MA-ControllerTimout=
  • Disabled-Other<= /li>
  • Error (= OPTIONAL)

The Error value MAY be used by the CPE to indicate a locally defined error condition.=

 

 

UseForMAControl

boolean

W

This parameter defines if the Schedule= is to be used for Actions that specific to the <= /span>

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC22793DUS70UWXCHMBA05z_--