From nobody Tue Jan 3 08:32:27 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19A12968B for ; Tue, 3 Jan 2017 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiVylWlpcwnn for ; Tue, 3 Jan 2017 08:32:24 -0800 (PST) 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 EDFE2129669 for ; Tue, 3 Jan 2017 08:32:23 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2DA8E6A1 for ; Tue, 3 Jan 2017 17:32:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FuxOlOg1Hokm for ; Tue, 3 Jan 2017 17:32:21 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 3 Jan 2017 17:32:21 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE7F220087 for ; Tue, 3 Jan 2017 17:32:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nvr-6Yh9ZQeV; Tue, 3 Jan 2017 17:32:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 704A720085; Tue, 3 Jan 2017 17:32:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5BA6F3DFF823; Tue, 3 Jan 2017 17:32:23 +0100 (CET) Date: Tue, 3 Jan 2017 17:32:23 +0100 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20170103163223.GA7367@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [lmap] /capabilities/task* vs /capabilities/tasks/task* X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:32:26 -0000 While implementing the /capabilities, I discovered that we do not have a node representing the whole task list in the capabilities branch, i.e., the tasks all appear right below /capabilities. I think it would be simpler and more consistent with all other lists we have if we would have a have tasks appear below /capabilities/tasks. (It would also make sense to move /capabilities before any configuration branches.) It is also a bit unclear how capability tasks and configured tasks work together. Right now, I can set the program property on both. Would it not be more natural to have the program set only on the capability and a configured task can only reference a capability task? Right now the behaviour is not really clear; I can try to configure a task to run any program, which is likely not what we want. Perhaps the idea is that I can only configure a program listed in the capability tasks. Perhaps we should instead have a way to reference a capability task from a task configuration (and if the reference can't be resolved, the referencing task (and any other indirect references to the referencing task) would not be applied config. Well, what we have may be possible to implement in a reasonable way, even though the details may be not entirely obvious. /js PS: I do not really know where the chairs think we are with the LMAP documents in their lifecycle. I have implemented what I described in the first paragraph in my sources, see the diff here: http://www.beadg.de/lmap/draft-ietf-lmap-yang-10-from-09.diff.html -- 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 Jan 3 12:27:45 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FA91296D4 for ; Tue, 3 Jan 2017 12:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zsdhouA6AuE for ; Tue, 3 Jan 2017 12:27:40 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65AD12944A for ; Tue, 3 Jan 2017 12:27:39 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id CD30E4ED78B23; Tue, 3 Jan 2017 20:27:35 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v03KRcOU008979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2017 20:27:38 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v03KRble008751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jan 2017 20:27:38 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Tue, 3 Jan 2017 15:27:37 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] /capabilities/task* vs /capabilities/tasks/task* Thread-Index: AQHSZfwRtfWHXaN6T0mH3TVV6/TYdKEnMX0Q Date: Tue, 3 Jan 2017 20:27:37 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20170103163223.GA7367@elstar.local> In-Reply-To: <20170103163223.GA7367@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:27:42 -0000 Juergen, The task capabilities just point to the registry objects (registry and role= s) - they don't have programs assigned. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, January 03, 2017 10:32 AM To: lmap@ietf.org Subject: [lmap] /capabilities/task* vs /capabilities/tasks/task* While implementing the /capabilities, I discovered that we do not have a no= de representing the whole task list in the capabilities branch, i.e., the t= asks all appear right below /capabilities. I think it would be simpler and = more consistent with all other lists we have if we would have a have tasks = appear below /capabilities/tasks. (It would also make sense to move /capabi= lities before any configuration branches.) It is also a bit unclear how capability tasks and configured tasks work tog= ether. Right now, I can set the program property on both. Would it not be more natural to have the program set only on the capability= and a configured task can only reference a capability task? Right now the behaviour is not really clear; I can try to configure a task = to run any program, which is likely not what we want. Perhaps the idea is t= hat I can only configure a program listed in the capability tasks. Perhaps = we should instead have a way to reference a capability task from a task con= figuration (and if the reference can't be resolved, the referencing task (a= nd any other indirect references to the referencing task) would not be appl= ied config. Well, what we have may be possible to implement in a reasonable= way, even though the details may be not entirely obvious. /js PS: I do not really know where the chairs think we are with the LMAP documents in their lifecycle. I have implemented what I described in the first paragraph in my sources, see the diff here: http://www.beadg.de/lmap/draft-ietf-lmap-yang-10-from-09.diff.html --=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 Wed Jan 4 14:46:01 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCADC12973E for ; Wed, 4 Jan 2017 14:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSX6242QR74J for ; Wed, 4 Jan 2017 14:45:57 -0800 (PST) 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 52BD31297BE for ; Wed, 4 Jan 2017 14:45:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD1DC6AC; Wed, 4 Jan 2017 23:45:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Utfm_YuoNjTd; Wed, 4 Jan 2017 23:45:54 +0100 (CET) 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, 4 Jan 2017 23:45:55 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F73B20086; Wed, 4 Jan 2017 23:45:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LlIPhhH-1vXo; Wed, 4 Jan 2017 23:45:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DABE320085; Wed, 4 Jan 2017 23:45:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 11C403E012B9; Wed, 4 Jan 2017 23:45:57 +0100 (CET) Date: Wed, 4 Jan 2017 23:45:56 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20170104224556.GA9362@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20170103163223.GA7367@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:46:00 -0000 On Tue, Jan 03, 2017 at 08:27:37PM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned. > In the information model; the data model also allows to have entries without a registry object which identifies a program to run (and this is what I have implemented). The question, however, is what exactly happens if a configured task refers to a capability task that does not exist. There are different options: a) The configuration is invalid. This is problematic in a YANG context since the idea is that validity of a configuration should not depend on the specific runtime capabilities of a system. b) The configuration may be valid but of configured tasks that refer to tasks that are not among the capabilities are not executed. >From a YANG perspective, semantics b) seem to make most sense. But then the question is how this plays with actions (that refer to configured tasks) and schedules (that refer to actions). There are again differnet options: b1) An action that refers to a configured task that references a non-existing capability is simply not executed. b2) Any schedule that includes an action that that refers to a configured task that references a non-existing capability is not executed. Recall that we have differnet execution modes. For pipelines schedules, b2) might make sense, for parallel or sequential schedules b1) might make sense. >From the discussion around intended and applied configs, it seems b2 seems to make most sense because b2) essentially says that any actions and their schedules that reference non-existing capabilities are not part of the applied config, that is, the applied config becomes a proper subset of the schedules (and not a subset of the actions of the schedules). /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 Jan 5 01:32:48 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5452D129475 for ; Thu, 5 Jan 2017 01:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZtbguEeAqKn for ; Thu, 5 Jan 2017 01:32:45 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91FD128E19 for ; Thu, 5 Jan 2017 01:32:45 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id D35343C3224F3; Thu, 5 Jan 2017 09:32:42 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id v059Wir5000702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2017 09:32:44 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 v059Wg1I003540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jan 2017 09:32:44 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.74]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 04:32:43 -0500 From: "Carey, Timothy (Nokia - US)" To: Juergen Schoenwaelder Thread-Topic: [lmap] /capabilities/task* vs /capabilities/tasks/task* Thread-Index: AQHSZfwRtfWHXaN6T0mH3TVV6/TYdKEnMX0QgAIO+wCAAGCf4A== Date: Thu, 5 Jan 2017 09:32:43 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A820D4A@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <20170103163223.GA7367@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20170104224556.GA9362@elstar.local> In-Reply-To: <20170104224556.GA9362@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:32:47 -0000 Juergen, I would agree that option B is the correct approach - but the action should= fail, correct? BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, January 04, 2017 4:46 PM To: Carey, Timothy (Nokia - US) Cc: lmap@ietf.org Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* On Tue, Jan 03, 2017 at 08:27:37PM +0000, Carey, Timothy (Nokia - US) wrote= : > Juergen, > The task capabilities just point to the registry objects (registry and ro= les) - they don't have programs assigned. > In the information model; the data model also allows to have entries withou= t a registry object which identifies a program to run (and this is what I h= ave implemented). The question, however, is what exactly happens if a configured task refers = to a capability task that does not exist. There are different options: a) The configuration is invalid. This is problematic in a YANG context since the idea is that validity of a configuration should not depend on the specific runtime capabilities of a system. b) The configuration may be valid but of configured tasks that refer to tasks that are not among the capabilities are not executed. >From a YANG perspective, semantics b) seem to make most sense. But then the= question is how this plays with actions (that refer to configured tasks) a= nd schedules (that refer to actions). There are again differnet options: b1) An action that refers to a configured task that references a non-existing capability is simply not executed. b2) Any schedule that includes an action that that refers to a configured task that references a non-existing capability is not executed. Recall that we have differnet execution modes. For pipelines schedules, b2)= might make sense, for parallel or sequential schedules b1) might make sense. >From the discussion around intended and applied configs, it seems b2 seems = to make most sense because b2) essentially says that any actions and their = schedules that reference non-existing capabilities are not part of the appl= ied config, that is, the applied config becomes a proper subset of the sche= dules (and not a subset of the actions of the schedules). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 5 06:41:53 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54B9129578 for ; Thu, 5 Jan 2017 06:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8epAPNHSFFc for ; Thu, 5 Jan 2017 06:41:50 -0800 (PST) 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 D23AF128B38 for ; Thu, 5 Jan 2017 06:41:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F3CE4754; Thu, 5 Jan 2017 15:41:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U6joVmMYXJYJ; Thu, 5 Jan 2017 15:41:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Jan 2017 15:41:47 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FB61200B8; Thu, 5 Jan 2017 15:41:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DlKVJKPI_6k9; Thu, 5 Jan 2017 15:41:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9BA1200AD; Thu, 5 Jan 2017 15:41:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 072DC3E024D5; Thu, 5 Jan 2017 15:41:47 +0100 (CET) Date: Thu, 5 Jan 2017 15:41:47 +0100 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Message-ID: <20170105144147.GA10175@elstar.local> Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20170103163223.GA7367@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A81C5C8@US70UWXCHMBA05.zam.alcatel-lucent.com> <20170104224556.GA9362@elstar.local> <9966516C6EB5FC4381E05BF80AA55F77012A820D4A@US70UWXCHMBA05.zam.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A820D4A@US70UWXCHMBA05.zam.alcatel-lucent.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "lmap@ietf.org" Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:41:52 -0000 Yes, one option is to simply have actions fail that refer to a capability that is not available. This also seems to be the simplest to implement. /js On Thu, Jan 05, 2017 at 09:32:43AM +0000, Carey, Timothy (Nokia - US) wrote: > Juergen, > > > I would agree that option B is the correct approach - but the action should fail, correct? > > BR, > Tim > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 04, 2017 4:46 PM > To: Carey, Timothy (Nokia - US) > Cc: lmap@ietf.org > Subject: Re: [lmap] /capabilities/task* vs /capabilities/tasks/task* > > On Tue, Jan 03, 2017 at 08:27:37PM +0000, Carey, Timothy (Nokia - US) wrote: > > Juergen, > > The task capabilities just point to the registry objects (registry and roles) - they don't have programs assigned. > > > > In the information model; the data model also allows to have entries without a registry object which identifies a program to run (and this is what I have implemented). > > The question, however, is what exactly happens if a configured task refers to a capability task that does not exist. There are different > options: > > a) The configuration is invalid. This is problematic in a YANG context > since the idea is that validity of a configuration should not > depend on the specific runtime capabilities of a system. > > b) The configuration may be valid but of configured tasks that refer > to tasks that are not among the capabilities are not executed. > > From a YANG perspective, semantics b) seem to make most sense. But then the question is how this plays with actions (that refer to configured tasks) and schedules (that refer to actions). There are again differnet options: > > b1) An action that refers to a configured task that references a > non-existing capability is simply not executed. > > b2) Any schedule that includes an action that that refers to a > configured task that references a non-existing capability is not > executed. > > Recall that we have differnet execution modes. For pipelines schedules, b2) might make sense, for parallel or sequential schedules > b1) might make sense. > > From the discussion around intended and applied configs, it seems b2 seems to make most sense because b2) essentially says that any actions and their schedules that reference non-existing capabilities are not part of the applied config, that is, the applied config becomes a proper subset of the schedules (and not a subset of the actions of the schedules). > > /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 Wed Jan 11 12:33:44 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8977B12985A; Wed, 11 Jan 2017 12:33:30 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148416681055.8115.7066571821356389191.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 12:33:30 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-15.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:33:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-15.txt Pages : 53 Date : 2017-01-11 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 12:34:49 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B630128B38; Wed, 11 Jan 2017 12:34:44 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148416688404.8232.17414639877698494632.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 12:34:44 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-yang-10.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:34: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 of the IETF. Title : A YANG Data Model for LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-yang-10.txt Pages : 60 Date : 2017-01-11 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-yang-10 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 Jan 13 02:16:07 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BB412943B for ; Fri, 13 Jan 2017 02:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbpl_NVlNdzy for ; Fri, 13 Jan 2017 02:16:04 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DDF1293E1 for ; Fri, 13 Jan 2017 02:16:03 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id 11so49093992qkl.3 for ; Fri, 13 Jan 2017 02:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VlIZmgbQZovKansS05wi6BgIPm4fBFh/T39YXWPyO5Y=; b=kKnPUiajIej48MdzbedDXVRS1v3qnLOYdQsnSidr/T1//2qSMa9LOIGvbm74Y0usiw mR7hc5/2BZ1x+VexZLxbyBxztpEB7CtbEkXiwCSHQWyestcj1X80GeBU2d57umt/meK8 Ri/B1nAwixUfYUYnhYoeD/EozJuNcUqqzT6R+bV0FpWBD9setapfANDxxll5N8dLjT4o AmrVVtg1mV6yGEWXsT8qmnUkV75bYHF94gZT1ztD6I2sfJUg/uQ+nWDKCE7bP7PccgJg AsWq+DRs0rzsMBczI/WIbR7q5NwB+6YxrWEzTL0vVFah1cKnIk/IxpqOzCFWhImsKiJR BhpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VlIZmgbQZovKansS05wi6BgIPm4fBFh/T39YXWPyO5Y=; b=KrAUGsbOp5C8gFnBUVKS/5Xfw/3F0Wbk1ob76amri74LGLAeHrrPCL9hAhfmgepfqb Ab1WUBxWy9cBiX2HFUeFtcf5iZYQm6F/izLt0HVSHI/iVGtGt/Z7tvOYuGhZ9/yh0MyZ nNJYXA1KDA7o9V3JFcp0E/GcqC2KAMrluJlE01MP7Lj9cflnYxrV0o9aUIF+vB248ExK 2827AO3uVeFI64YDTemBKIvTFfYfK5m72GIs4bNQ8T/MF029QKcn2pufmoBHQ9KdZmJu qld77vPv5IZMCXHtuLkoB3QZ1lFdN4tKNlF5PsHSIFW80KsEe/iUDrxz5JotXp07/4sP FldA== X-Gm-Message-State: AIkVDXIRtMb0XqiXfQS9SdpmX8W6EPJoSJY4Ha6ivHIJP08AL3LPG0BtynhGH62XhPJODH8nJvqfFJDQnN6J7w== X-Received: by 10.55.43.158 with SMTP id r30mr20227854qkr.28.1484302562726; Fri, 13 Jan 2017 02:16:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.11 with HTTP; Fri, 13 Jan 2017 02:16:02 -0800 (PST) From: Dan Romascanu Date: Fri, 13 Jan 2017 12:16:02 +0200 Message-ID: To: lmap@ietf.org Content-Type: multipart/alternative; boundary=001a1149430efda0c20545f71e0e Archived-At: Subject: [lmap] downref in draft-ietf-lmap-information-model-15.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:16:06 -0000 --001a1149430efda0c20545f71e0e Content-Type: text/plain; charset=UTF-8 Hi, I should have noticed this early. While preparing the IESG submission I ran idnits and it rightly shouts that [RFC7594] is a downref. Do we really need this as a Normative Reference? I feel not, and I suggest to move it to Informative References. If nobody has a problem with this, I would suggest that Juergen issues a revised version to fix. If you see a problem, please say it. Thanks and Regards, Dan --001a1149430efda0c20545f71e0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I should have noticed this= early. While preparing the IESG submission I ran idnits and it rightly sho= uts that [RFC7594] is a downref. Do we really need this as a Normative Refe= rence? I feel not, and I suggest to move it to Informative References.
=
If nobody has a problem with this, I would suggest that Juergen i= ssues a revised version to fix. If you see a problem, please say it.
Thanks and Regards,

Dan

--001a1149430efda0c20545f71e0e-- From nobody Fri Jan 13 05:19:12 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80D1295F2 for ; Fri, 13 Jan 2017 05:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.955 X-Spam-Level: X-Spam-Status: No, score=-6.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LoRhAU5qlcn for ; Fri, 13 Jan 2017 05:19:08 -0800 (PST) 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 12E3B129BC4 for ; Fri, 13 Jan 2017 05:19:07 -0800 (PST) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 13 Jan 2017 13:19:05 +0000 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 13 Jan 2017 13:19:05 +0000 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.1210.3; Fri, 13 Jan 2017 13:19:05 +0000 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.1210.000; Fri, 13 Jan 2017 13:19:05 +0000 From: To: , Thread-Topic: [lmap] downref in draft-ietf-lmap-information-model-15.txt Thread-Index: AQHSbYYXMqaV45iVZUmjKgnUY2QT/KE2Y0+A Date: Fri, 13 Jan 2017 13:19:05 +0000 Message-ID: <9f226ecca6174261a9383590b5bb64ba@rew09926dag03b.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.216.161.29] Content-Type: multipart/alternative; boundary="_000_9f226ecca6174261a9383590b5bb64barew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [lmap] downref in draft-ietf-lmap-information-model-15.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 13:19:11 -0000 --_000_9f226ecca6174261a9383590b5bb64barew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGFncmVlIHRoYXQgdGhlIExNQVAgRnJhbWV3b3JrIHNob3VsZCBiZSBhbiBJbmZvcm1h dGl2ZSByZWYuDQpCZXN0IHdpc2hlcw0KcGhpbA0KRnJvbTogbG1hcCBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbiBSb21hc2NhbnUNClNlbnQ6IDEzIEphbnVh cnkgMjAxNyAxMDoxNg0KVG86IGxtYXBAaWV0Zi5vcmcNClN1YmplY3Q6IFtsbWFwXSBkb3ducmVm IGluIGRyYWZ0LWlldGYtbG1hcC1pbmZvcm1hdGlvbi1tb2RlbC0xNS50eHQNCg0KSGksDQpJIHNo b3VsZCBoYXZlIG5vdGljZWQgdGhpcyBlYXJseS4gV2hpbGUgcHJlcGFyaW5nIHRoZSBJRVNHIHN1 Ym1pc3Npb24gSSByYW4gaWRuaXRzIGFuZCBpdCByaWdodGx5IHNob3V0cyB0aGF0IFtSRkM3NTk0 XSBpcyBhIGRvd25yZWYuIERvIHdlIHJlYWxseSBuZWVkIHRoaXMgYXMgYSBOb3JtYXRpdmUgUmVm ZXJlbmNlPyBJIGZlZWwgbm90LCBhbmQgSSBzdWdnZXN0IHRvIG1vdmUgaXQgdG8gSW5mb3JtYXRp dmUgUmVmZXJlbmNlcy4NCklmIG5vYm9keSBoYXMgYSBwcm9ibGVtIHdpdGggdGhpcywgSSB3b3Vs ZCBzdWdnZXN0IHRoYXQgSnVlcmdlbiBpc3N1ZXMgYSByZXZpc2VkIHZlcnNpb24gdG8gZml4LiBJ ZiB5b3Ugc2VlIGEgcHJvYmxlbSwgcGxlYXNlIHNheSBpdC4NClRoYW5rcyBhbmQgUmVnYXJkcywN CkRhbg0K --_000_9f226ecca6174261a9383590b5bb64barew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5ZZXMsIEkgYWdyZWUgdGhhdCB0aGUgTE1BUCBGcmFtZXdvcmsgc2hv dWxkIGJlDQogYW4gSW5mb3JtYXRpdmUgcmVmLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVzdCB3aXNoZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbG1hcCBbbWFpbHRvOmxtYXAtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGFuIFJvbWFzY2FudTxicj4NCjxi PlNlbnQ6PC9iPiAxMyBKYW51YXJ5IDIwMTcgMTA6MTY8YnI+DQo8Yj5Ubzo8L2I+IGxtYXBAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2xtYXBdIGRvd25yZWYgaW4gZHJhZnQtaWV0Zi1s bWFwLWluZm9ybWF0aW9uLW1vZGVsLTE1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBzaG91bGQgaGF2ZSBub3RpY2VkIHRoaXMgZWFybHku IFdoaWxlIHByZXBhcmluZyB0aGUgSUVTRyBzdWJtaXNzaW9uIEkgcmFuIGlkbml0cyBhbmQgaXQg cmlnaHRseSBzaG91dHMgdGhhdCBbUkZDNzU5NF0gaXMgYSBkb3ducmVmLiBEbyB3ZSByZWFsbHkg bmVlZCB0aGlzIGFzIGEgTm9ybWF0aXZlIFJlZmVyZW5jZT8gSSBmZWVsIG5vdCwgYW5kIEkgc3Vn Z2VzdA0KIHRvIG1vdmUgaXQgdG8gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4gPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SWYgbm9ib2R5IGhhcyBhIHByb2JsZW0gd2l0aCB0aGlzLCBJIHdvdWxkIHN1Z2dlc3Qg dGhhdCBKdWVyZ2VuIGlzc3VlcyBhIHJldmlzZWQgdmVyc2lvbiB0byBmaXguIElmIHlvdSBzZWUg YSBwcm9ibGVtLCBwbGVhc2Ugc2F5IGl0Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5r cyBhbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGFuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9f226ecca6174261a9383590b5bb64barew09926dag03bdomain1sy_-- From nobody Fri Jan 13 05:32:29 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271D129BEC for ; Fri, 13 Jan 2017 05:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsXpvxxTvMVg for ; Fri, 13 Jan 2017 05:32:25 -0800 (PST) Received: from mail.chartercom.com (mail.chartercom.com [24.176.92.28]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BCA129BEA for ; Fri, 13 Jan 2017 05:32:24 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.33,221,1477976400"; d="scan'208,217"; a="76787671" Received: from unknown (HELO SC58MEXGP007.CORP.CHARTERCOM.com) ([172.24.253.135]) by mail.chartercom.com with ESMTP; 13 Jan 2017 07:14:59 -0600 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM (172.24.253.136) by SC58MEXGP007.CORP.CHARTERCOM.com (172.24.253.135) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Jan 2017 07:32:22 -0600 Received: from SC58MEXGP008.CORP.CHARTERCOM.COM ([fe80::719f:6d16:1ed5:5b5c]) by SC58MEXGP008.CORP.CHARTERCOM.com ([fe80::719f:6d16:1ed5:5b5c%19]) with mapi id 15.00.1104.000; Fri, 13 Jan 2017 07:32:22 -0600 From: "Weil, Jason A" To: "lmap@ietf.org" Thread-Topic: IETF 97 Notes Thread-Index: AQHSbaF4xxJzup4Xe0iYCnRwpntdbw== Date: Fri, 13 Jan 2017 13:32:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.24.253.192] Content-Type: multipart/alternative; boundary="_000_D49E41206657Ejasonweilchartercom_" MIME-Version: 1.0 Archived-At: Subject: [lmap] IETF 97 Notes X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 13:32:26 -0000 --_000_D49E41206657Ejasonweilchartercom_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Could whoever took notes during the IETF97 meeting in Seoul please send the= m to me? I believe it was Holger, but I apologize if I have that wrong Holg= er. Thanks! Jason E-MAIL CONFIDENTIALITY NOTICE: = The contents of this e-mail message and any attachments are intended solely= for the addressee(s) and may contain confidential and/or legally privilege= d information. If you are not the intended recipient of this message or if = this message has been addressed to you in error, please immediately alert t= he sender by reply e-mail and then delete this message and any attachments.= If you are not the intended recipient, you are notified that any use, diss= emination, distribution, copying, or storage of this message or any attachm= ent is strictly prohibited. --_000_D49E41206657Ejasonweilchartercom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9BE76227BA97FB4EB597B183015A6E2C@chartercom.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Could whoever took notes during the IETF97 meeting in Seoul please sen= d them to me? I believe it was Holger, but I apologize if I have that wrong= Holger.

Thanks!

Jason
The contents of this e-mail message and
any attachments are intended so= lely for the
addressee(s) and may contain confidential
and/or legal= ly privileged information. If you
are not the intended recipient of this= message
or if this message has been addressed to you
in error, plea= se immediately alert the sender
by reply e-mail and then delete this mes= sage
and any attachments. If you are not the
intended recipient, yo= u are notified that
any use, dissemination, distribution, copying,
o= r storage of this message or any attachment
is strictly prohibited. --_000_D49E41206657Ejasonweilchartercom_-- From nobody Fri Jan 13 08:13:47 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9A112970F; Fri, 13 Jan 2017 08:13:45 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148432402597.26871.16002203487038555066.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 08:13:45 -0800 Archived-At: Cc: lmap@ietf.org Subject: [lmap] I-D Action: draft-ietf-lmap-information-model-16.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 16:13:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Information Model for Large-Scale Measurement Platforms (LMAP) Authors : Trevor Burbridge Philip Eardley Marcelo Bagnulo Juergen Schoenwaelder Filename : draft-ietf-lmap-information-model-16.txt Pages : 53 Date : 2017-01-13 Abstract: This Information Model applies to the Measurement Agent within a Large-Scale Measurement Platform. As such it outlines the information that is (pre-)configured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol and device independent view of the Measurement Agent that can be implemented via one or more Control and Report protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-information-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lmap-information-model-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-information-model-16 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 Jan 23 07:51:54 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B4C129637 for ; Mon, 23 Jan 2017 07:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBHAfUbVVR9M for ; Mon, 23 Jan 2017 07:51:52 -0800 (PST) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) (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 AF760129601 for ; Mon, 23 Jan 2017 07:51:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id E5756232D79 for ; Mon, 23 Jan 2017 13:51:48 -0200 (BRST) Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYXKC6Xq-0yA for ; Mon, 23 Jan 2017 13:51:48 -0200 (BRST) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: holger@nic.br) by mail.nic.br (Postfix) with ESMTPSA id 1B77D232D48 for ; Mon, 23 Jan 2017 13:51:48 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1485186708; bh=ORS9nWmYeNgJdK5Y7r3i55DUG4aWrRty5o/KxZEXOgc=; h=From:Subject:Date:To:From; b=Qw3Z1FV0DKwTzcGnhrDpq/Xy6lPxqGyxpjCiK+JnB1aKmtrhCWtnOSXS9eXJJnWli s7VFpZeRsj0bwBwlGoeiBP1dCVxE0JnvP9g09ygIfK/LD+RDGpcz7IkKsoSFKsJG02 Zioyb6NBpyhX+53B5mZrhA+/aU2FuS/GQwWwVmHo= From: Holger Wiehen Content-Type: multipart/alternative; boundary="Apple-Mail=_6204876F-4364-45CC-A7EC-6418068580A3" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <08B9F120-0766-4B21-8676-16C9B0D5180F@nic.br> Date: Mon, 23 Jan 2017 13:51:47 -0200 To: lmap@ietf.org X-Mailer: Apple Mail (2.3259) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 1B77D232D48 Archived-At: Subject: [lmap] [information model] ma-task-object issues X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:51:53 -0000 --Apple-Mail=_6204876F-4364-45CC-A7EC-6418068580A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi.=20 I noticed 2 issues with the ma-task-object (LMAP Information Model). 1) Missing protocol information (OWAMP, TWAMP,=E2=80=A6)=20 In order to measure the metric specified on a task, coordination will be = necessary between the Measurement Agent and a Measurement Peer, in most = cases. Shouldn=E2=80=99t the task indicate the measurement protocol to use, = besides the metric to be measured? In my understanding, the metric = coming from the Ippm-Metrics-Registry will be protocol agnostic. Today we rely on some implicit default for the measurement protocol. = Alternatively the task could inform which protocol is to be used for a = given metric. This would apply to capabilities (=E2=80=9CI support = metric X measured with Owamp=E2=80=9D) and instructions (=E2=80=9Cmeasure = metric Y, using Owamp=E2=80=9D). 2) Inconsistency with the Yang Data Model The information model only specifies =E2=80=9Cma-task-functions=E2=80=9D = (Ippm Metrics) for a task. The data model specifies =E2=80=9Cfunctions=E2=80=9D (Ippm Metrics) and = alternatively a =E2=80=9Cprogram=E2=80=9D (local executable) to perform = a task. Should the =E2=80=9Cprogram=E2=80=9D attribute appear in the information = model? Holger Wiehen= --Apple-Mail=_6204876F-4364-45CC-A7EC-6418068580A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi. 

I noticed 2 issues with the = ma-task-object (LMAP Information Model).


1) Missing protocol information (OWAMP, = TWAMP,=E2=80=A6) 

In order to measure the metric specified on a task, = coordination will be necessary between the Measurement Agent and a Measurement = Peer, in most cases.
Shouldn=E2=80=99t the = task indicate the measurement protocol to use, besides the metric to be = measured?  In my understanding, the metric coming from the = Ippm-Metrics-Registry will be protocol agnostic.
Today we rely on some implicit default for the measurement = protocol. Alternatively the task could inform which protocol is to be = used for a given metric. This would apply to capabilities (=E2=80=9CI = support metric X measured with Owamp=E2=80=9D) and instructions = (=E2=80=9Cmeasure metric Y, using Owamp=E2=80=9D).


2) Inconsistency with the Yang Data Model

The information model = only specifies =E2=80=9Cma-task-functions=E2=80=9D (Ippm Metrics) for a = task.
The data model specifies = =E2=80=9Cfunctions=E2=80=9D (Ippm Metrics) and alternatively a =E2=80=9Cprogram= =E2=80=9D (local executable) to perform a task.
Should the =E2=80=9Cprogram=E2=80=9D attribute appear in the = information model?



Holger Wiehen
= --Apple-Mail=_6204876F-4364-45CC-A7EC-6418068580A3-- From nobody Mon Jan 23 10:41:13 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB169129795 for ; Mon, 23 Jan 2017 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrcp55Sk1NGP for ; Mon, 23 Jan 2017 10:41:10 -0800 (PST) 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 56FB112978B for ; Mon, 23 Jan 2017 10:41:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 24778700; Mon, 23 Jan 2017 19:41:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bqoITEDSDss6; Mon, 23 Jan 2017 19:41:07 +0100 (CET) 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, 23 Jan 2017 19:41:08 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CD05200AB; Mon, 23 Jan 2017 19:41:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mf2mlVatNt35; Mon, 23 Jan 2017 19:41:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 376CA200A8; Mon, 23 Jan 2017 19:41:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4222D3E4770E; Mon, 23 Jan 2017 19:41:10 +0100 (CET) Date: Mon, 23 Jan 2017 19:41:10 +0100 From: Juergen Schoenwaelder To: Holger Wiehen Message-ID: <20170123184110.GC33438@elstar.local> Mail-Followup-To: Holger Wiehen , lmap@ietf.org References: <08B9F120-0766-4B21-8676-16C9B0D5180F@nic.br> 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: <08B9F120-0766-4B21-8676-16C9B0D5180F@nic.br> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] [information model] ma-task-object issues X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:41:12 -0000 On Mon, Jan 23, 2017 at 01:51:47PM -0200, Holger Wiehen wrote: > Hi. > > I noticed 2 issues with the ma-task-object (LMAP Information Model). > > > 1) Missing protocol information (OWAMP, TWAMP,…) > > In order to measure the metric specified on a task, coordination will be necessary between the Measurement Agent and a Measurement Peer, in most cases. > Shouldn’t the task indicate the measurement protocol to use, besides the metric to be measured? In my understanding, the metric coming from the Ippm-Metrics-Registry will be protocol agnostic. > Today we rely on some implicit default for the measurement protocol. Alternatively the task could inform which protocol is to be used for a given metric. This would apply to capabilities (“I support metric X measured with Owamp”) and instructions (“measure metric Y, using Owamp”). > Simply use task options. Good enough until we have sufficient operational experience that something more elaborate is needed. > 2) Inconsistency with the Yang Data Model > > The information model only specifies “ma-task-functions” (Ippm Metrics) for a task. > The data model specifies “functions” (Ippm Metrics) and alternatively a “program” (local executable) to perform a task. > Should the “program” attribute appear in the information model? > This difference is by design and not by accident. The information model view is that the registry takes care of everything. The data model view is that there exists stuff that is not covered by a (metrics) registry. (And my implementation does not use the registry at all right now since I have not really figured out how to make this work.) I think it is fine if a data model 'expands' the information model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 23 11:22:30 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AC51294F7 for ; Mon, 23 Jan 2017 11:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=oZ/QPPCH; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=so558xe0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oKWunAzdKiH for ; Mon, 23 Jan 2017 11:22:27 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA17C129496 for ; Mon, 23 Jan 2017 11:22:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5408520744 for ; Mon, 23 Jan 2017 14:22:26 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 23 Jan 2017 14:22:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ULrxNhECrY2g0pOJx6S7ewsO+Os=; b=oZ/QPP CHW17wsvcCXCbauiAKjXkIjMvK4EVgdIULq2Si/n1wZ2f2BNOF2xdT25DPvoGPsD p4PLaQlReU4GNhIheNJQGCQ2Af0FbSjF5aggDpI/gWIc6koDKFV3XuxegMu2kLYt C7+isJyhVf+1Zhmc+q0jYQPYcns/HD9dhPG1o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ULrxNhECrY2g0p OJx6S7ewsO+Os=; b=so558xe0a3+dkSP6LbDfzcUWQOjCGaYNONA8zLvgFQ1cns YY7X+l1pTOokvHEX4RUE5dCWMtlGhdySdagy+QaWHZ7THJZzlTTrxJxzCDouuVOC XtXEeCz1jvkmUk6XHxub1GXWrdc4p2cqKaainaQ+2wJVgCIRRRlJGecriu/PQ= X-ME-Sender: X-Sasl-enc: 6ic9g+jB1q96jU9B43iwQU6T8b7nxjOluivmNHdvJJK0 1485199346 Received: from dhcp-10-150-9-148.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A03124066 for ; Mon, 23 Jan 2017 14:22:26 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> Date: Mon, 23 Jan 2017 14:22:25 -0500 To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:22:29 -0000 I have reviewed this document in preparation for IETF last call. I have = a few substantive comments and questions that I=E2=80=99d like to = discuss before issuing the LC. I=E2=80=99ve also included some nits and = minor comments that should be resolved together with any IETF LC = comments. Substantive comments and questions: For a number of my comments below, it might be the case that you think = the detail I'm asking for does not belong in the information model, but = would be more appropriate in a specification of a specific data model or = protocol. I'm not particularly wedded to any of these details appearing = here, but I do think they need to appear somewhere, so if they're not = going to be specified here I think this document needs to explain that = data models and/or protocols need to specify them. =3D String type definition =3D Is it expected that data models and/or protocols will define what = character encoding is expected for the string data type? If so, it would = be good to say that somewhere. =3D Credentials: Section 3.1, 3.2, 3.8, 6 =3D I have a couple of questions about how credentials are defined and used = in this document: (1) Is it expected that data models and/or protocols will define the = 'credential' type and format? If so, it would help to make that clear up = front. (2) Are ma-preconfig-credentials and ma-config-credentials meant to be = credentials only for the MA to be authenticated by a Controller or = Collector? I assume that the credentials that allow the MA to = authenticate other endpoints, and to protect communications to those = endpoints, are stored in ma-channel-credentials, but it would help to = clarify which set of credentials each of these fields is referring to. (3) I'm a little concerned that both ma-config-control-channels and = ma-config-credentials are mandatory fields in ma-config-obj, and that = the point of having them specified there is to override the = pre-configuration information. If I'm understanding correctly, this = means that an MA could be preconfigured with certificates it uses to = authenticate and encrypt its initial request to a Controller, and the = Controller could then respond by saying, "don't use those credentials = for yourself or for me, but use these other ones instead." How can an MA = then distinguish between a Controller it should trust and one that has = been compromised? I know the bootstrapping process is generally out of = scope for LMAP, but that scenario seems to imply a security threat that = was not specifically contemplated in the framework. Since the fields are = being defined here, I think this document needs to discuss these = implications, or explain whether there is some (two-way) exchange = expected between the MA and the Controller using all the pre-configured = credentials that needs to happen before the MA agrees to use different = sets of credentials provisioned by the Controller. =20 =3D Section 3.1.1, 3.4.1, 3.5.3 =3D I think you need to specify the scope within which uuids are expected to = be unique, and whether the same uuids are expected to be re-used for = config, logging, and status. =3D Section 3.2 =3D I think it would be good to provide some guidance about how NOT to = construct a group ID. E.g., I would assume putting sensitive information = like "low-income neighborhood" or similar in the group ID would be = ill-advised, because even within the single administrative domain where = MAs are communicating with Controllers and Collectors, there may be = people who are authorized to process the measurement data but not know = that level of detail about which kind of group a device/connection = belongs to. In that kind of case a mapping between an opaque identifier = in the group ID and more contextual information on the = Controller/Collector back-end would be wise. I think the draft would = benefit from some explanation of that here or in Section 6 with a = cross-reference back to here. =3D Section 3.5.2 =3D What would be the cause for defining different versions of the same = task? Also, since the two different versions would have the same name = (presumably), I think you need to state of the expected scope of = uniqueness of the task name. =3D Section 3.5.3 =3D Why does this object need both an agent ID and a device ID? Is the = device ID here expected to be the same as the one that gets = pre-configured on the device? What is an MA supposed to put in the = device-id field defined here if there was no device ID pre-configured = (since in pre-configuration it's an optional field)? =3D Section 3.5.4 =3D Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and = ma-status-schedule-overlaps meant to report counters over all of time, = or only since ma-status-last-started? I think this needs to be = clarified. =3D Section 3.5.5 =3D Same question as 3.5.4 for the counters in this section. =3D Section 3.9 and 3.9.1 =3D "Both measurement and non-measurement Tasks have registry entries to enable the MA to uniquely identify the Task it should execute and retrieve the schema for any parameters that may be passed to the Task. ... A configured task can be referenced by its name and it contains a set of URIs to link to registry entries or a local specification of the task. ... ma-task-functions: A possibly empty unordered set of registry entries identifying the functions of the configured task." I have a couple of questions about this: (1) Are there any registries being defined for non-measurement tasks, or = is this just indicating that such registries could be created? I think = it would help to clarify since there is obviously the metrics registry = for measurement tasks. (2) I don't understand "or a local specification of the task." Is that = local specification supposed to be represented with a local URI, the = same as other registry objects? Or if not, is ma-task-functions not = properly defined, since it's possible to reference something other than = a registry entry there? =3D Section 3.10.1 =3D I don't understand why ma-registry-role is defined here. In = draft-ietf-ippm-metric-registry, the role is part of the registry entry, = so by specifying the URI, one should know which role is the appropriate = one for that entry.=20 Nits and minor comments: =3D Section 1 =3D s/Large Measurement platform/Large-Scale Measurement platform/ =3D Section 3 =3D (1) s/(from a measurement to reporting or communicating with the = Controller)/(including measurements or reporting or communicating with = the Controller)/ (2) It seems a bit odd that Action first appears in Figure 1 but is not = included in the enumerated list of objects above it. (3) "Every Action contained in a Schedule is defined as a Task. ... = Tasks can implement a variety of different types of Actions." I think = this will be confusing to readers because it's circular. It sounds like = all Actions are Tasks but Tasks are comprised of Actions; I think the = abstraction needs to be explained better, and made consistent. See also = sections 3.3 and 3.7: "An Action is a Task with additional specific = parameters." I think it would be better to define what an Action is once = at its earliest use. =3D Section 3.1.1 =3D s/set of tasks objects/set of task objects/ =3D Section 3.2 =3D OLD The reporting of a Group ID without the MA ID allows the MA to remain anonymous NEW The reporting of a Group ID without the MA ID may allow the MA to remain anonymous (Rationale: Given all of the other data and potential identifiers the MA = may report, it may still be possible for a Collector or other entity to = identify the MA -- not providing an agent ID helps, but does not = guarantee anonymity.) =3D Secion 3.3 =3D s/This enabled fine/This enables fine/ =3D Section 3.3.2 =3D Please add a citation for POSIX.2 fnmatch(). =3D Section 3.5.4, 3.5.5, and 3.5.6 =3D To reduce redundancy I would suggest defining the values 'enabled,' = 'suppressed,' 'disabled,' and 'running' outside of all of these sections = one time and then within the field definitions just saying which values = are valid for each field that uses them. =3D Section 3.6 =3D s/Where the Configuration/Whereas the Configuration/ (Right? I couldn't quite parse the sentence.) =3D Section 3.6.2 =3D I think it would be good to provide a short explanation in the text as = to why RFC 3339 format is not being used for = ma-report-result-cycle-number. =3D Section 3.8 =3D s/it's own/its own/ =3D Section 6 =3D OLD This would, for example, allow the MA to remain anonymous NEW This may, for example, allow the MA to remain anonymous (Same rationale as 3.2.) From nobody Mon Jan 23 13:15:22 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB531298BB for ; Mon, 23 Jan 2017 13:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJYXoha56L4Q for ; Mon, 23 Jan 2017 13:15:19 -0800 (PST) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 4D4BC1298B5 for ; Mon, 23 Jan 2017 13:15:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id E7C46232E51; Mon, 23 Jan 2017 19:15:16 -0200 (BRST) Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw4tiuxQJAUA; Mon, 23 Jan 2017 19:15:16 -0200 (BRST) Received: from 5.140.net.registro.br (unknown [IPv6:2001:12ff:0:5::140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: holger@nic.br) by mail.nic.br (Postfix) with ESMTPSA id B0635232D1C; Mon, 23 Jan 2017 19:15:16 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1485206116; bh=Lyopqp4FxP5yr+IqBVP2OTKPbwSXpC/czpY+58fesIk=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=laHuqnfyo8w1Qlvai2Gc5pjseGm3DYgdcAbdvMPLeKzbxAN2Ml2EpZO4tSUUFLHdT 8UFiTmTup2nzpXWx6H9bCkSTFWQrUM7bTP6wUyjJb3wjpQH+kTYgyZJivOKwJdNmd9 oFL1mawb9XlpblJYKKz03ZyQe15XZib5JsZxWq5g= From: Holger Wiehen Message-Id: <4CF28928-361A-4D56-BEF5-ACC411A84526@nic.br> Content-Type: multipart/alternative; boundary="Apple-Mail=_759D4A88-04FE-4166-A5F4-537EBB557346" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 23 Jan 2017 19:15:16 -0200 In-Reply-To: <20170123184110.GC33438@elstar.local> To: Juergen Schoenwaelder References: <08B9F120-0766-4B21-8676-16C9B0D5180F@nic.br> <20170123184110.GC33438@elstar.local> X-Mailer: Apple Mail (2.3259) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br B0635232D1C Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] [information model] ma-task-object issues X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 21:15:21 -0000 --Apple-Mail=_759D4A88-04FE-4166-A5F4-537EBB557346 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juergen. I agree. Thank=E2=80=99s for your clarification. Holger Wiehen. > On 23 Jan 2017, at 16:41, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jan 23, 2017 at 01:51:47PM -0200, Holger Wiehen wrote: >> Hi.=20 >>=20 >> I noticed 2 issues with the ma-task-object (LMAP Information Model). >>=20 >>=20 >> 1) Missing protocol information (OWAMP, TWAMP,=E2=80=A6)=20 >>=20 >> In order to measure the metric specified on a task, coordination will = be necessary between the Measurement Agent and a Measurement Peer, in = most cases. >> Shouldn=E2=80=99t the task indicate the measurement protocol to use, = besides the metric to be measured? In my understanding, the metric = coming from the Ippm-Metrics-Registry will be protocol agnostic. >> Today we rely on some implicit default for the measurement protocol. = Alternatively the task could inform which protocol is to be used for a = given metric. This would apply to capabilities (=E2=80=9CI support = metric X measured with Owamp=E2=80=9D) and instructions (=E2=80=9Cmeasure = metric Y, using Owamp=E2=80=9D). >>=20 >=20 > Simply use task options. Good enough until we have sufficient > operational experience that something more elaborate is needed. >=20 >> 2) Inconsistency with the Yang Data Model >>=20 >> The information model only specifies =E2=80=9Cma-task-functions=E2=80=9D= (Ippm Metrics) for a task. >> The data model specifies =E2=80=9Cfunctions=E2=80=9D (Ippm Metrics) = and alternatively a =E2=80=9Cprogram=E2=80=9D (local executable) to = perform a task. >> Should the =E2=80=9Cprogram=E2=80=9D attribute appear in the = information model? >>=20 >=20 > This difference is by design and not by accident. The information > model view is that the registry takes care of everything. The data > model view is that there exists stuff that is not covered by a > (metrics) registry. (And my implementation does not use the registry > at all right now since I have not really figured out how to make this > work.) I think it is fine if a data model 'expands' the information > model. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --Apple-Mail=_759D4A88-04FE-4166-A5F4-537EBB557346 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Juergen.

I agree.
Thank=E2=80=99s for your = clarification.

Holger Wiehen.


On 23 Jan 2017, at 16:41, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On = Mon, Jan 23, 2017 at 01:51:47PM -0200, Holger Wiehen wrote:
Hi.

I noticed 2 issues with the ma-task-object (LMAP Information = Model).


1) Missing protocol = information (OWAMP, TWAMP,=E2=80=A6)

In = order to measure the metric specified on a task, coordination will be = necessary between the Measurement Agent and a Measurement Peer, in most = cases.
Shouldn=E2=80=99t the task indicate the measurement = protocol to use, besides the metric to be measured?  In my = understanding, the metric coming from the Ippm-Metrics-Registry will be = protocol agnostic.
Today we rely on some implicit default = for the measurement protocol. Alternatively the task could inform which = protocol is to be used for a given metric. This would apply to = capabilities (=E2=80=9CI support metric X measured with Owamp=E2=80=9D) = and instructions (=E2=80=9Cmeasure metric Y, using Owamp=E2=80=9D).


Simply use task = options. Good enough until we have sufficient
operational = experience that something more elaborate is needed.

2) Inconsistency with = the Yang Data Model

The information model = only specifies =E2=80=9Cma-task-functions=E2=80=9D (Ippm Metrics) for a = task.
The data model specifies =E2=80=9Cfunctions=E2=80=9D = (Ippm Metrics) and alternatively a =E2=80=9Cprogram=E2=80=9D (local = executable) to perform a task.
Should the =E2=80=9Cprogram=E2= =80=9D attribute appear in the information model?


This difference is by design and = not by accident. The information
model view is that the = registry takes care of everything. The data
model view is = that there exists stuff that is not covered by a
(metrics) = registry. (And my implementation does not use the registry
at all right now since I have not really figured out how to = make this
work.) I think it is fine if a data model = 'expands' the information
model.

/js

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

= --Apple-Mail=_759D4A88-04FE-4166-A5F4-537EBB557346-- From nobody Tue Jan 24 08:03:16 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43F129A9B for ; Tue, 24 Jan 2017 08:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=aBSDIl9n; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=FwqKijPJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06TREi1ysOG8 for ; Tue, 24 Jan 2017 08:03:13 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C348012961D for ; Tue, 24 Jan 2017 08:03:13 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1D28020A63 for ; Tue, 24 Jan 2017 11:03:13 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 24 Jan 2017 11:03:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=NPP153WiS1Go9uw tmOLgxYpbZYM=; b=aBSDIl9nNK4xhWnOdbzF8HLI6NIbCklWCFrw93OAkc2oD8V GqCJVnH1Di/7chk+k93A2b2bCLY5Cz27MLPFAFnzvH6OoJu2p975dIGpRwnTZHql aZAt+GpaE8kdKpMN/Hd1w5+7C8doNXwN0WQe9d291xMSXCGYlxlwj53wMS3M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=NPP153WiS1Go9uwtmOLgxYpbZYM=; b=FwqKijPJgDby0+5CsV5q RUOYNlddF74qv4qj8LCZAFS9AKDpStosDJ0gj/e9mJvVOEJyXvyAi9AbK3DCOQJ3 kHQervzB+4WAsjkIdP/eRChMrKAgAZWIN7Cd0zwuIQkEdukDu/gak9m3+q1I/AWw 7z/ifHNEY7BIqHm58hq0HZQ= X-ME-Sender: X-Sasl-enc: L3Y6Xl8CmgsjJQlKz16PA//i7j/klgYmj2HTRsCIjLjc 1485273792 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 8DBD024428 for ; Tue, 24 Jan 2017 11:03:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> Date: Tue, 24 Jan 2017 11:03:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> To: lmap@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:03:15 -0000 > On Jan 23, 2017, at 2:22 PM, Alissa Cooper wrote: >=20 > (2) Are ma-preconfig-credentials and ma-config-credentials meant to be = credentials only for the MA to be authenticated by a Controller or = Collector? I assume that the credentials that allow the MA to = authenticate other endpoints, and to protect communications to those = endpoints, are stored in ma-channel-credentials, but it would help to = clarify which set of credentials each of these fields is referring to. Just to reinforce this, now that I=E2=80=99m doing a review of = draft-ietf-lmap-yang: it seems that the model in = draft-ietf-netconf-netconf-client-server defines both the client and = server credentials. So if that is supposed to fulfill the channel = credentials in the information model, what happens if the = ma-config-credentials for the MA are different than the ones in the = ma-channel-obj for the MA? Which ones is the MA supposed to use? Thanks, Alissa= From nobody Tue Jan 24 08:04:52 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0A5129A9B for ; Tue, 24 Jan 2017 08:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=DkgD7Jz1; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=o2iqZYYv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7XayJScDlpO for ; Tue, 24 Jan 2017 08:04:50 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAE412961D for ; Tue, 24 Jan 2017 08:04:50 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 66844204E8 for ; Tue, 24 Jan 2017 11:04:49 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 24 Jan 2017 11:04:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=hr1AZ58iT61x8dZcPTj7DFMJvM8=; b=DkgD7J z1p3WD+Gfr/zxtboPYR0s5GqKWJDO1G3b/gWl8lRu/fyN+L2lp90C8+dNvX6i4+/ cAb2DNIfJXdM3LWNLCu2gxU3QZc/KDfXrfWa4Gu17KmmLgE/1sD0FFgPVtKPQUbV UYbjI8WTNCi3JrU3CaIbA3l7sL092EY3TWtg8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=hr1AZ58iT61x8d ZcPTj7DFMJvM8=; b=o2iqZYYvWTEwv+Q0VGY3wpmLKqz6q983Jy7v4E2sVNJ79e k1bc6i4CIxXycrewTTEpToaxJFI7MA6EgmdUAov0AGRFz5f2gK7321K0IS38Yh2V lOpbK87mTPru95/PGob4emgEgX3O32DEwMeq7m0ZSL+8MYe/73Oy7O99K5bUc= X-ME-Sender: X-Sasl-enc: E4PU8WRhhC1bbea1MVuYqPuLPel1cNRounYb9J4byEpH 1485273889 Received: from sjc-alcoop-8818.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id D799B244D6 for ; Tue, 24 Jan 2017 11:04:48 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> Date: Tue, 24 Jan 2017 11:04:47 -0500 To: lmap@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:04:51 -0000 I have reviewed this document in preparation for IETF last call. I have = a few substantive comments and questions that I=E2=80=99d like to = discuss before issuing the LC. I=E2=80=99ve also included some nits and = minor comments that should be resolved together with any IETF LC = comments. Substantive comments and questions: =3D Section 3 =3D "Configuration Information: This is modeled in the /lmap/agent subtree, the /lmap/schedules subtree, and the /lmap/tasks subtree described below. Some items have been left out because they are expected to be dealt with by the underlying protocol." I think this needs some further elaboration about the items that have = been left out. As far as I can tell the only items from the information = model that this data model does not define are ma-config-credentials and = ma-config-control-channels. There is already text further below to = explain the expectation about how channels will be modeled, which should = be referenced here. Is there not something more specific that can be = said about how credentials will be handled/modeled, assuming the = "underlying protocol" referenced for configuration is NETCONF? =3D Section 4.2 =3D (1) "It is generally a good idea to always configure an end time and to refresh the configuration of event object as needed to ensure that agents that loose connectivity to their controller do not continue their tasks forever." =20 This is more of a comment for the information model, but if this is = worth saying here, shouldn't it (also) be mentioned in the corresponding = information model definition in draft-ietf-lmap-information-model? This = doesn't seem specific to this particular data model. (2) For all the counters defined here, I think you need to specify the = time period over which the counts are to be calculated. (3) 'list action { key name; description "An action describes a task that is invoked by the schedule. Multiple actions are invoked sequentially.";' I don't get this -- doesn't the execution mode define whether the = actions are executed sequentially, in parallel, or pipelined? (4) "A queue is internally used to pass results to another schedule." I thought it was up to the implementation to decide how to implement = this? (5) I don't understand why the 'program' elements are included in the = task configurations and capabilities. It doesn't seem wise to allow the = controller to tell the MA which program it needs to use to complete a = task, and I don't understand why the MA would need to communicate that = information to the controller either. I thought the recent list = discussion indicated that if an MA was not capable of performing an = action, that action would simply fail, which seems like all that is = needed. Nits and minor comments: =3D Section 4.1 =3D Please provide a reference for ISO 8601. =3D Section 4.2 =3D s/loose connectivity/lose connectivity/ s/schedule determins/schedule determines/ s/A set of month/A set of months/ s/A set of second/A set of seconds/ =3D Section 5 =3D (1) Just a suggestion, but I think this is worth calling out = specifically: OLD Unauthorized access may leak measurement results. NEW Unauthorized access may leak measurement results, including from passive = measurements. (2) "Implementers MUST taken care that option names and values are passed literally to programs. In particular, it MUST be avoided that any shell expansions are performed that may alter the option names and values." This text strikes me as a bit odd. Surely there are a whole selection of = good programming practices that are necessary to ensure that things = don't go haywire when implementing LMAP -- why call out these two with = normative recommendations? Why does this guidance only apply to options? = I would recommend having this text be non-normative, but if you do keep = it I would suggest the following: Implementers MUST take care that option names and values are passed literally to programs. In particular, shell expansions that may alter the option names and = values MUST NOT be performed. From nobody Tue Jan 24 08:07:29 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843E51294B6 for ; Tue, 24 Jan 2017 08:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdGzAro1TPMD for ; Tue, 24 Jan 2017 08:07:24 -0800 (PST) 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 193A212961D for ; Tue, 24 Jan 2017 08:07:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 75398700; Tue, 24 Jan 2017 17:07:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pD6_PVYuzgyZ; Tue, 24 Jan 2017 17:07:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jan 2017 17:07:20 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D1A5200AC; Tue, 24 Jan 2017 17:07:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YPVcHShYfLfb; Tue, 24 Jan 2017 17:07:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C20BC200AB; Tue, 24 Jan 2017 17:07:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 795A53E498E8; Tue, 24 Jan 2017 17:07:21 +0100 (CET) Date: Tue, 24 Jan 2017 17:07:21 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170124160720.GB36955@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:07:27 -0000 Alissa, thanks for your review - much appreciated. Some of the questions indeed touch on the question 'what needs to be dealt with in an information model and what can be left out', which I think has no clear answer. Please see my response inline... On Mon, Jan 23, 2017 at 02:22:25PM -0500, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. I have a= few substantive comments and questions that I=E2=80=99d like to discuss be= fore issuing the LC. I=E2=80=99ve also included some nits and minor comment= s that should be resolved together with any IETF LC comments. >=20 > Substantive comments and questions: >=20 > For a number of my comments below, it might be the case that you think th= e detail I'm asking for does not belong in the information model, but would= be more appropriate in a specification of a specific data model or protoco= l. I'm not particularly wedded to any of these details appearing here, but = I do think they need to appear somewhere, so if they're not going to be spe= cified here I think this document needs to explain that data models and/or = protocols need to specify them. >=20 > =3D String type definition =3D >=20 > Is it expected that data models and/or protocols will define what charact= er encoding is expected for the string data type? If so, it would be good t= o say that somewhere. My assumption always was that a string means a (possibly restricted) set of Unicode or ISO/IEC 10646 characters. The '(possibly restricted)' comes from the fact that data modeling languages such as YANG excludes certain control characters, surrogate blocks and noncharacters. I will get back to this at the end. > =3D Credentials: Section 3.1, 3.2, 3.8, 6 =3D >=20 > I have a couple of questions about how credentials are defined and used i= n this document: >=20 > (1) Is it expected that data models and/or protocols will define the 'cre= dential' type and format? If so, it would help to make that clear up front. Yes. I will get back to this at the end. =20 > (2) Are ma-preconfig-credentials and ma-config-credentials meant to be cr= edentials only for the MA to be authenticated by a Controller or Collector?= I assume that the credentials that allow the MA to authenticate other endp= oints, and to protect communications to those endpoints, are stored in ma-c= hannel-credentials, but it would help to clarify which set of credentials e= ach of these fields is referring to. This is a very good question and I do not recall how we got to what we have. The channel credentials are the credentials used between an MA and a Controller or Collector. It is less clear what the other device credentials are really used for. Trevor, do you recall and can you clarify the situation? My interpretation is that the configured credentials are, for example, the credentials needed for trusted X.509 authorities, i.e., they are not channel specific - the credentials an MA has to use for a specific channel but the credentials needed to verify the credentials of a remote peer. Trevor? > (3) I'm a little concerned that both ma-config-control-channels and ma-co= nfig-credentials are mandatory fields in ma-config-obj, and that the point = of having them specified there is to override the pre-configuration informa= tion. If I'm understanding correctly, this means that an MA could be precon= figured with certificates it uses to authenticate and encrypt its initial r= equest to a Controller, and the Controller could then respond by saying, "d= on't use those credentials for yourself or for me, but use these other ones= instead." How can an MA then distinguish between a Controller it should tr= ust and one that has been compromised? I know the bootstrapping process is = generally out of scope for LMAP, but that scenario seems to imply a securit= y threat that was not specifically contemplated in the framework. Since the= fields are being defined here, I think this document needs to discuss thes= e implications, or explain whether there is some (two-way) exchange expecte= d between the MA and the Controller using all the pre-configured credential= s that needs to happen before the MA agrees to use different sets of creden= tials provisioned by the Controller. I think the assumption here is that the MA trusts the controller which has credentials matching the MA's pre-configured credentials. If this trusted controller then later installs new credentials, this leads to a trust relationship to another controller. Are you requesting that this should be more clearly discussed in the Security Considerations? Or are you saying this is a bad idea and we should not allow a controller to provision any credentials? > =3D Section 3.1.1, 3.4.1, 3.5.3 =3D >=20 > I think you need to specify the scope within which uuids are expected to = be unique, and whether the same uuids are expected to be re-used for config= , logging, and status. I think the idea is to use version 4 uuids which have a very low probability of collision. Generally, the expectation is that these uuids are unique within an installation of a large-scale measurement system. I will get back to this at the end. > =3D Section 3.2 =3D >=20 > I think it would be good to provide some guidance about how NOT to constr= uct a group ID. E.g., I would assume putting sensitive information like "lo= w-income neighborhood" or similar in the group ID would be ill-advised, bec= ause even within the single administrative domain where MAs are communicati= ng with Controllers and Collectors, there may be people who are authorized = to process the measurement data but not know that level of detail about whi= ch kind of group a device/connection belongs to. In that kind of case a map= ping between an opaque identifier in the group ID and more contextual infor= mation on the Controller/Collector back-end would be wise. I think the draf= t would benefit from some explanation of that here or in Section 6 with a c= ross-reference back to here. I agree. And I think this is not only relevant for group IDs but equally applies to tags or other names that can be freely choosen. What about this at the end of the Security Considerations: [...] In addition, users of this Information Model are advised to choose identifiers for Group IDs, tags or names of information model objects (e.g., configured tasks, schedules or actions) that do not reveal any sensitive information to people authorized to process measurement results but who are not authorized to know details about the Measurement Agents that were used to perform the measurement. =20 > =3D Section 3.5.2 =3D >=20 > What would be the cause for defining different versions of the same task?= Also, since the two different versions would have the same name (presumabl= y), I think you need to state of the expected scope of uniqueness of the ta= sk name. > Names of objects are generally assumed to be unique within an MA. The version here is essentially used to be able to distinguish different versions of an implementation of a given metric. I might have MAs with an old version of a metric implementation with specific bugs and I might have MAs with a new version of a metric implementation with different kind of bugs. > =3D Section 3.5.3 =3D >=20 > Why does this object need both an agent ID and a device ID? Is the device= ID here expected to be the same as the one that gets pre-configured on the= device? What is an MA supposed to put in the device-id field defined here = if there was no device ID pre-configured (since in pre-configuration it's a= n optional field)? We could make the ma-status-device-id optional to be consistent. > =3D Section 3.5.4 =3D >=20 > Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and = ma-status-schedule-overlaps meant to report counters over all of time, or o= nly since ma-status-last-started? I think this needs to be clarified. Counters are not expected to persist across reboots. I will get back to this at the end. =20 > =3D Section 3.5.5 =3D >=20 > Same question as 3.5.4 for the counters in this section. Same as above. > =3D Section 3.9 and 3.9.1 =3D >=20 > "Both measurement and non-measurement > Tasks have registry entries to enable the MA to uniquely identify the > Task it should execute and retrieve the schema for any parameters > that may be passed to the Task. > ... > A configured task can be referenced by its name and it > contains a set of URIs to link to registry entries or a local > specification of the task. > ... > ma-task-functions: A possibly empty unordered set of registry > entries identifying the functions of the > configured task." >=20 > I have a couple of questions about this: >=20 > (1) Are there any registries being defined for non-measurement tasks, or = is this just indicating that such registries could be created? I think it w= ould help to clarify since there is obviously the metrics registry for meas= urement tasks. Creating an LMAP task registry was briefly discussed on the mailing list but so far no concrete proposal has been written. I think the definition in section 3.9 is actually fine since it does not refer explicitely to the IPPM metrics registry. > (2) I don't understand "or a local specification of the task." Is that lo= cal specification supposed to be represented with a local URI, the same as = other registry objects? Or if not, is ma-task-functions not properly define= d, since it's possible to reference something other than a registry entry t= here? The set of referenced regristry entry entries can be empty. The phrase 'or a local specification of the task' is indeed confusing. What is meant here is a task that is essentially well-known by its name. For example, there is a task called 'traceroute' or 'iperf' and I expect it to do a traceroute or to run iperf measurements. Perhaps the text should be changed to read: A configured task can be referenced by its name and it contains a possibly empty set of URIs to link to registry entries. > =3D Section 3.10.1 =3D >=20 > I don't understand why ma-registry-role is defined here. In draft-ietf-ip= pm-metric-registry, the role is part of the registry entry, so by specifyin= g the URI, one should know which role is the appropriate one for that entry= =2E=20 > An entry in the metrics registry may define multiple roles. The ma-registry-role selects which of these roles are instantiated. =20 > Nits and minor comments: >=20 > =3D Section 1 =3D >=20 > s/Large Measurement platform/Large-Scale Measurement platform/ fixed > =3D Section 3 =3D >=20 > (1) s/(from a measurement to reporting or communicating with the Controll= er)/(including measurements or reporting or communicating with the Controll= er)/ fixed > (2) It seems a bit odd that Action first appears in Figure 1 but is not i= ncluded in the enumerated list of objects above it. I agree - Actions came in later and it still shows. I will see what I can do to reword this. What about this: > (3) "Every Action contained in a Schedule is defined as a Task. ... Tasks= can implement a variety of different types of Actions." I think this will = be confusing to readers because it's circular. It sounds like all Actions a= re Tasks but Tasks are comprised of Actions; I think the abstraction needs = to be explained better, and made consistent. See also sections 3.3 and 3.7:= "An Action is a Task with additional specific parameters." I think it woul= d be better to define what an Action is once at its earliest use. What about this (right below Figure 1): =20 The primary function of an MA is to execute Schedules. A Schedule, which is triggered by an Event, executes a number of Actions. An Action refers to a Configured Task and it may feed results to a Destination Schedule. Both, Actions and Configured Tasks can provide parameters, represented as Action Options and Task Options. > =3D Section 3.1.1 =3D >=20 > s/set of tasks objects/set of task objects/ fixed > =3D Section 3.2 =3D >=20 > OLD > The reporting of a > Group ID without the MA ID allows the MA to remain anonymous >=20 > NEW > The reporting of a > Group ID without the MA ID may allow the MA to remain anonymous >=20 > (Rationale: Given all of the other data and potential identifiers the MA = may report, it may still be possible for a Collector or other entity to ide= ntify the MA -- not providing an agent ID helps, but does not guarantee ano= nymity.) fixed > =3D Secion 3.3 =3D >=20 > s/This enabled fine/This enables fine/ fixed > =3D Section 3.3.2 =3D >=20 > Please add a citation for POSIX.2 fnmatch(). done =20 > =3D Section 3.5.4, 3.5.5, and 3.5.6 =3D >=20 > To reduce redundancy I would suggest defining the values 'enabled,' 'supp= ressed,' 'disabled,' and 'running' outside of all of these sections one tim= e and then within the field definitions just saying which values are valid = for each field that uses them. > I do no think the benefit is worth the effort. We do not have any notion of user defined types so far and introducing it to save a few words does in my view not make the specification clearer. > =3D Section 3.6 =3D >=20 > s/Where the Configuration/Whereas the Configuration/ >=20 > (Right? I couldn't quite parse the sentence.) Yes, fixed. > =3D Section 3.6.2 =3D >=20 > I think it would be good to provide a short explanation in the text as to= why RFC 3339 format is not being used for ma-report-result-cycle-number. The point is that the cycle-number is a fixed-point _number_. > =3D Section 3.8 =3D >=20 > s/it's own/its own/ fixed > =3D Section 6 =3D >=20 > OLD > This would, for example, allow the MA to remain > anonymous >=20 > NEW > This may, for example, allow the MA to remain > anonymous fixed To address the questions (above) concerning the semantics of several base types we have used, I think it makes sense to add the following to section 2: The object definitions use a couple of base types that are defined as follows: int A type representing signed or unsigned integer numbers. This information model does not define a precision nor does it make a distinction between signed and unsigned number ranges. This type is also used to represent enumerations. boolean A type representing a boolean value. string A type representing a human-readable strings consisting of a (possibly restricted) subset of Unicode and ISO/IEC 10646 [ISO.10646] characters. datetime A type representing a date and time using the Gregorian calendar. The datetime format MUST conform to RFC 3339 [RFC3339]. uuid A type representing Universally Unique IDentifier (UUID( as defined in RFC 4122 [RFC4122]. The UUID values are expected to be unique within an installation of a large- scale measurement system. uri A type representing a Uniform Resource Identifier as defined in STD 66 [RFC3986]. ip-address A type representing an IP address. This type supports both IPv4 and IPv6 addresses. counter A non-negative integer that monotonically increases. Counters may have discontinuities and they are not expected to persist across restarts. credentials An opaque type representing credentials needed by a cryptographic mechanism to security communication. Data models must expand this opaque type as needed and required by the security protocols utilized. data An opaque type representing data obtained from measurements. Names of objects are generally assumed to be unique within an implementation. A diff of -16 to my working copy (of -17) can be found here: http://beadg.de/lmap/ /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 Tue Jan 24 12:23:10 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA31296FC for ; Tue, 24 Jan 2017 12:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya_3SvuguAsU for ; Tue, 24 Jan 2017 12:23:06 -0800 (PST) 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 3A98E1294F7 for ; Tue, 24 Jan 2017 12:23:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0DE936A8; Tue, 24 Jan 2017 21:23:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qlxDKFH74jOB; Tue, 24 Jan 2017 21:23:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jan 2017 21:23:04 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CDB0200AC; Tue, 24 Jan 2017 21:23:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l4rvpBciTv6k; Tue, 24 Jan 2017 21:23:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC974200AB; Tue, 24 Jan 2017 21:23:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 83D593E4A30C; Tue, 24 Jan 2017 21:23:05 +0100 (CET) Date: Tue, 24 Jan 2017 21:23:05 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170124202305.GA38068@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> 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: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:23:09 -0000 Alissa, thanks for your review comments. Let me see what can be done to address them... On Tue, Jan 24, 2017 at 11:04:47AM -0500, Alissa Cooper wrote: > I have reviewed this document in preparation for IETF last call. I have a few substantive comments and questions that I’d like to discuss before issuing the LC. I’ve also included some nits and minor comments that should be resolved together with any IETF LC comments. > > Substantive comments and questions: > > = Section 3 = > > "Configuration Information: This is modeled in the /lmap/agent > subtree, the /lmap/schedules subtree, and the /lmap/tasks subtree > described below. Some items have been left out because they are > expected to be dealt with by the underlying protocol." > > I think this needs some further elaboration about the items that have been left out. As far as I can tell the only items from the information model that this data model does not define are ma-config-credentials and ma-config-control-channels. There is already text further below to explain the expectation about how channels will be modeled, which should be referenced here. Is there not something more specific that can be said about how credentials will be handled/modeled, assuming the "underlying protocol" referenced for configuration is NETCONF? > I think this is related to the issue you raised for the information model. Until we are clear what the MA credentials not associated to a channel were intended to be used for, I can't really answer this specific question. > = Section 4.2 = > > (1) "It is generally a good idea to always configure > an end time and to refresh the configuration > of event object as needed to ensure that agents > that loose connectivity to their controller > do not continue their tasks forever." > > This is more of a comment for the information model, but if this is worth saying here, shouldn't it (also) be mentioned in the corresponding information model definition in draft-ietf-lmap-information-model? This doesn't seem specific to this particular data model. I see your point. I think it makes sense to note this in the second item 4. of section 3 of the information model. (I will change the numbering of the second list to use letters to make it easier to refer to things.) [...] For Event objects specifying a series of events, it is generally a good idea to configure an end time and to refresh the end time as needed to ensure that MAs that loose connectivity to their controller do not continue executing Schedules forever. > (2) For all the counters defined here, I think you need to specify the time period over which the counts are to be calculated. We use counters as defined in RFC 6991 and I think the definition in RFC 6991 takes care of things. > (3) 'list action { > key name; > description > "An action describes a task that is invoked by the > schedule. Multiple actions are invoked sequentially.";' > > I don't get this -- doesn't the execution mode define whether the actions are executed sequentially, in parallel, or pipelined? Good catch. Changed this to: list action { key name; description "An action describes a task that is invoked by the schedule. Multiple actions are invoked according to the execution-mode of the schedule."; > (4) "A queue is internally used to pass > results to another schedule." > > I thought it was up to the implementation to decide how to implement this? OK. I meanwhile understand that the word 'queue' has too many connotations. Is 'buffer' a less problematic term? The key here is that the data producer and the data consumer are in general not running at the time and hence data needs to be stored temporarily somewhere. I will replace queue with buffer for now. > (5) I don't understand why the 'program' elements are included in the task configurations and capabilities. It doesn't seem wise to allow the controller to tell the MA which program it needs to use to complete a task, and I don't understand why the MA would need to communicate that information to the controller either. I thought the recent list discussion indicated that if an MA was not capable of performing an action, that action would simply fail, which seems like all that is needed. There are multiple things: (a) How do I tell which task I want to have executed? The information model assumes that this can be done with the help of a registry. The YANG data model, in addition, allows to use a simple 'program name'. Note that this is a choice, i.e., you either use a registry or a program name, but not both. The registry at the end is just some level of indirection - but this indirection also requires to have tasks registered in a registry. Right now, the implementation I know of only supports program names. (b) The task list in the capabilities branch serves as an inventory, i.e., it tells the controller which tasks are supported by a given implementation. The other task list defined options that are used when a certain task is invoked (the Task Configuration in the information model). If a controller configures a task that the agent does support (i.e., it is not listed in the capability tasks), it will not be executed. Note that a capability task name 'traceroute' exposed by the LMAP agent does not necessarily mean that there is a program called traceroute at the operating system level. In fact, an implementation could choose to run traceroute internally without an explicit system level process (like RIPE Atlas did everything in a big event loop, not sure whether this is still the case). > Nits and minor comments: > > = Section 4.1 = > > Please provide a reference for ISO 8601. added > = Section 4.2 = > > s/loose connectivity/lose connectivity/ > > s/schedule determins/schedule determines/ > > s/A set of month/A set of months/ > > s/A set of second/A set of seconds/ fixed > = Section 5 = > > (1) Just a suggestion, but I think this is worth calling out specifically: > > OLD > Unauthorized access may leak measurement results. > > NEW > Unauthorized access may leak measurement results, including from passive measurements. added > (2) "Implementers MUST taken care that > option names and values are passed literally to programs. In > particular, it MUST be avoided that any shell expansions are > performed that may alter the option names and values." > > This text strikes me as a bit odd. Surely there are a whole selection of good programming practices that are necessary to ensure that things don't go haywire when implementing LMAP -- why call out these two with normative recommendations? Why does this guidance only apply to options? I would recommend having this text be non-normative, but if you do keep it I would suggest the following: > > Implementers MUST take care that > option names and values are passed literally to programs. In > particular, shell expansions that may alter the option names and values MUST NOT be performed. I have no strong opinion on MUST vs must here and I usually happily follow the advice of IESG members on RFC 2119 keywords. ;-) Yes, there are many ways to write broken code but this is such a common problem that I think can't hurt to remind implementors. A diff of -10 to my working copy (of -11) can be found here: http://beadg.de/lmap/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 24 12:28:03 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4F1296FC for ; Tue, 24 Jan 2017 12:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdQHg6_ySN-U for ; Tue, 24 Jan 2017 12:28:00 -0800 (PST) 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 9D3CE129715 for ; Tue, 24 Jan 2017 12:28:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B05D781; Tue, 24 Jan 2017 21:27:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id za_3_pVjDxFc; Tue, 24 Jan 2017 21:27:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Jan 2017 21:27:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1954F200AC; Tue, 24 Jan 2017 21:27:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pu1FDy3FLOI5; Tue, 24 Jan 2017 21:27:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF0FD200AB; Tue, 24 Jan 2017 21:27:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DEBD53E4A3C3; Tue, 24 Jan 2017 21:28:01 +0100 (CET) Date: Tue, 24 Jan 2017 21:28:01 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com, philip.eardley@bt.com Message-ID: <20170124202801.GB38068@elstar.local> Mail-Followup-To: trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org, Alissa Cooper References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> 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: <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Alissa Cooper , lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:28:02 -0000 Trevor and Phil, do you recall the reason why we have channel credentials and MA global credentials? How are the MA global credentials supposed to be used? /js On Tue, Jan 24, 2017 at 11:03:11AM -0500, Alissa Cooper wrote: > > > On Jan 23, 2017, at 2:22 PM, Alissa Cooper wrote: > > > > (2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA to authenticate other endpoints, and to protect communications to those endpoints, are stored in ma-channel-credentials, but it would help to clarify which set of credentials each of these fields is referring to. > > Just to reinforce this, now that I’m doing a review of draft-ietf-lmap-yang: it seems that the model in draft-ietf-netconf-netconf-client-server defines both the client and server credentials. So if that is supposed to fulfill the channel credentials in the information model, what happens if the ma-config-credentials for the MA are different than the ones in the ma-channel-obj for the MA? Which ones is the MA supposed to use? > > Thanks, > Alissa > _______________________________________________ > 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 Wed Jan 25 01:02:22 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0425F12984C for ; Wed, 25 Jan 2017 01:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.956 X-Spam-Level: X-Spam-Status: No, score=-6.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV9QYeblfJ0X for ; Wed, 25 Jan 2017 01:02:18 -0800 (PST) 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 3E582129893 for ; Wed, 25 Jan 2017 01:02:17 -0800 (PST) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 25 Jan 2017 09:02:13 +0000 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 25 Jan 2017 09:02:15 +0000 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.1210.3; Wed, 25 Jan 2017 09:02:11 +0000 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.1210.000; Wed, 25 Jan 2017 09:02:12 +0000 From: To: , Thread-Topic: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 Thread-Index: AQHSdoBcqRaIefyC2Ey00/mwC9xFFKFI5XUw Date: Wed, 25 Jan 2017 09:02:11 +0000 Message-ID: <248d21f7ec4546b0af1fe98e604a4c8e@rew09926dag03c.domain1.systemhost.net> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> <20170124202801.GB38068@elstar.local> In-Reply-To: <20170124202801.GB38068@elstar.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 09:02:21 -0000 SW5pdGlhbGx5IHRoZSBNQSBjcmVkZW50aWFscyB3ZXJlIHRoZSBwcml2YXRlIGNyZWRlbnRpYWxz IG9mIHRoZSBNQSBhbmQgdGhlIGNoYW5uZWwgY3JlZGVudGlhbHMgd2VyZSB0aGUgcHVibGljIGNy ZWRlbnRpYWxzIGZvciBlYWNoIGNoYW5uZWwgZW5kLXBvaW50Lg0KDQpUcmV2b3IuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0 bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdIA0KU2VudDogMjQgSmFudWFy eSAyMDE3IDIwOjI4DQpUbzogQnVyYnJpZGdlLFQsVHJldm9yLFRVQjggUiA8dHJldm9yLmJ1cmJy aWRnZUBidC5jb20+OyBFYXJkbGV5LFBMLFBoaWxpcCxUVUI4IFIgPHBoaWxpcC5lYXJkbGV5QGJ0 LmNvbT4NCkNjOiBsbWFwQGlldGYub3JnOyBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5p bj4NClN1YmplY3Q6IFJlOiBbbG1hcF0gQUQgZXZhbHVhdGlvbjogZHJhZnQtaWV0Zi1sbWFwLWlu Zm9ybWF0aW9uLW1vZGVsLTE2DQoNClRyZXZvciBhbmQgUGhpbCwNCg0KZG8geW91IHJlY2FsbCB0 aGUgcmVhc29uIHdoeSB3ZSBoYXZlIGNoYW5uZWwgY3JlZGVudGlhbHMgYW5kIE1BIGdsb2JhbCBj cmVkZW50aWFscz8gSG93IGFyZSB0aGUgTUEgZ2xvYmFsIGNyZWRlbnRpYWxzIHN1cHBvc2VkIHRv IGJlIHVzZWQ/DQoNCi9qcw0KDQpPbiBUdWUsIEphbiAyNCwgMjAxNyBhdCAxMTowMzoxMUFNIC0w NTAwLCBBbGlzc2EgQ29vcGVyIHdyb3RlOg0KPiANCj4gPiBPbiBKYW4gMjMsIDIwMTcsIGF0IDI6 MjIgUE0sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPiB3cm90ZToNCj4gPiANCj4g PiAoMikgQXJlIG1hLXByZWNvbmZpZy1jcmVkZW50aWFscyBhbmQgbWEtY29uZmlnLWNyZWRlbnRp YWxzIG1lYW50IHRvIGJlIGNyZWRlbnRpYWxzIG9ubHkgZm9yIHRoZSBNQSB0byBiZSBhdXRoZW50 aWNhdGVkIGJ5IGEgQ29udHJvbGxlciBvciBDb2xsZWN0b3I/IEkgYXNzdW1lIHRoYXQgdGhlIGNy ZWRlbnRpYWxzIHRoYXQgYWxsb3cgdGhlIE1BIHRvIGF1dGhlbnRpY2F0ZSBvdGhlciBlbmRwb2lu dHMsIGFuZCB0byBwcm90ZWN0IGNvbW11bmljYXRpb25zIHRvIHRob3NlIGVuZHBvaW50cywgYXJl IHN0b3JlZCBpbiBtYS1jaGFubmVsLWNyZWRlbnRpYWxzLCBidXQgaXQgd291bGQgaGVscCB0byBj bGFyaWZ5IHdoaWNoIHNldCBvZiBjcmVkZW50aWFscyBlYWNoIG9mIHRoZXNlIGZpZWxkcyBpcyBy ZWZlcnJpbmcgdG8uDQo+IA0KPiBKdXN0IHRvIHJlaW5mb3JjZSB0aGlzLCBub3cgdGhhdCBJ4oCZ bSBkb2luZyBhIHJldmlldyBvZiBkcmFmdC1pZXRmLWxtYXAteWFuZzogaXQgc2VlbXMgdGhhdCB0 aGUgbW9kZWwgaW4gZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtY2xpZW50LXNlcnZlciBkZWZp bmVzIGJvdGggdGhlIGNsaWVudCBhbmQgc2VydmVyIGNyZWRlbnRpYWxzLiBTbyBpZiB0aGF0IGlz IHN1cHBvc2VkIHRvIGZ1bGZpbGwgdGhlIGNoYW5uZWwgY3JlZGVudGlhbHMgaW4gdGhlIGluZm9y bWF0aW9uIG1vZGVsLCB3aGF0IGhhcHBlbnMgaWYgdGhlIG1hLWNvbmZpZy1jcmVkZW50aWFscyBm b3IgdGhlIE1BIGFyZSBkaWZmZXJlbnQgdGhhbiB0aGUgb25lcyBpbiB0aGUgbWEtY2hhbm5lbC1v YmogZm9yIHRoZSBNQT8gV2hpY2ggb25lcyBpcyB0aGUgTUEgc3VwcG9zZWQgdG8gdXNlPw0KPiAN Cj4gVGhhbmtzLA0KPiBBbGlzc2ENCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbG1hcCBtYWlsaW5nIGxpc3QNCj4gbG1hcEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtYXANCg0KLS0gDQpKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJl bWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Wed Jan 25 01:18:36 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B988D1298A4 for ; Wed, 25 Jan 2017 01:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IauCcw07H8L4 for ; Wed, 25 Jan 2017 01:18:34 -0800 (PST) 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 04E8512989C for ; Wed, 25 Jan 2017 01:18:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C86B378D; Wed, 25 Jan 2017 10:18:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BuZH43Op94UN; Wed, 25 Jan 2017 10:18:30 +0100 (CET) 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, 25 Jan 2017 10:18:32 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42874200AC; Wed, 25 Jan 2017 10:18:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AELUtcFrZK9A; Wed, 25 Jan 2017 10:18:31 +0100 (CET) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93F46200AB; Wed, 25 Jan 2017 10:18:31 +0100 (CET) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 6F9C33E4AF9B; Wed, 25 Jan 2017 10:18:35 +0100 (CET) Date: Wed, 25 Jan 2017 10:18:35 +0100 From: Juergen Schoenwaelder To: trevor.burbridge@bt.com Message-ID: <20170125091835.GB40411@elstar.jacobs.jacobs-university.de> Mail-Followup-To: trevor.burbridge@bt.com, philip.eardley@bt.com, alissa@cooperw.in, lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> <20170124202801.GB38068@elstar.local> <248d21f7ec4546b0af1fe98e604a4c8e@rew09926dag03c.domain1.systemhost.net> 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: <248d21f7ec4546b0af1fe98e604a4c8e@rew09926dag03c.domain1.systemhost.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: philip.eardley@bt.com, alissa@cooperw.in, lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 09:18:36 -0000 Trevor, this is also the explanation I came up with but the document does not really explain this. Alissa, would this resolve your comment if I try to add text that tries to explain this distinction? Would it help to add examples? - SSH host keys are I think examples of MA credentials while SSH user authentication keys and authorization lists are channel credentials. - X.509 certificates defining trust to X.509 root authorities are examples of MA credentials. while X.509 client ceritifcates for TLS communication are channel credentials. (Lets see whether I got this right. ;-) /js On Wed, Jan 25, 2017 at 09:02:11AM +0000, trevor.burbridge@bt.com wrote: > Initially the MA credentials were the private credentials of the MA and the channel credentials were the public credentials for each channel end-point. > > Trevor. > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 24 January 2017 20:28 > To: Burbridge,T,Trevor,TUB8 R ; Eardley,PL,Philip,TUB8 R > Cc: lmap@ietf.org; Alissa Cooper > Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 > > Trevor and Phil, > > do you recall the reason why we have channel credentials and MA global credentials? How are the MA global credentials supposed to be used? > > /js > > On Tue, Jan 24, 2017 at 11:03:11AM -0500, Alissa Cooper wrote: > > > > > On Jan 23, 2017, at 2:22 PM, Alissa Cooper wrote: > > > > > > (2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA to authenticate other endpoints, and to protect communications to those endpoints, are stored in ma-channel-credentials, but it would help to clarify which set of credentials each of these fields is referring to. > > > > Just to reinforce this, now that I’m doing a review of draft-ietf-lmap-yang: it seems that the model in draft-ietf-netconf-netconf-client-server defines both the client and server credentials. So if that is supposed to fulfill the channel credentials in the information model, what happens if the ma-config-credentials for the MA are different than the ones in the ma-channel-obj for the MA? Which ones is the MA supposed to use? > > > > Thanks, > > Alissa > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 25 07:52:15 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002441299B9 for ; Wed, 25 Jan 2017 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=w5/ytcfF; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=YP79UrS1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwI4BeI0QGvD for ; Wed, 25 Jan 2017 07:52:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7FC12984C for ; Wed, 25 Jan 2017 07:52:11 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AB7E92098E; Wed, 25 Jan 2017 10:52:09 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 25 Jan 2017 10:52:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=JcAgmFat8DwVyVlsZhik5G8U470=; b=w5/ytc fFk0q6UHy0zeUkX+krf/9MwDJ+UPWiQtRMs7BOdyVdLBkooO9SMOaXzoGDVwqJb1 /ST1dtMtMpMA/bjM0gpawRE2QN3AYmKC81i69TFmtUAfAqw1IaJfW2E/juMvisnt A8P85M62qWM/t36YBMxdH1sXLAu9k1UBnKS68= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=JcAgmFat8DwVyV lsZhik5G8U470=; b=YP79UrS1DRJ5Kf7zTcFFJxY4wqcKcZsh6c68VALIvjOg7W NpDgMwVQl/HY7ZpytE72DU+JVVK4UJJor+8o6LxgSR+Nxmc8+z9ilSg1+jYxS1vT 7xzDIwUVzhC2tHmZq6FytdA1N9CzixRRgZDeAF0fu05Hd5j0NHBhDA8ZaS+JE= X-ME-Sender: X-Sasl-enc: 6owyE2ANE4b6anbXJCrS3ZTrBclOAqEeVyuTkRAcw4nC 1485359529 Received: from dhcp-10-150-9-181.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 35ADE7E2B0; Wed, 25 Jan 2017 10:52:09 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_04E6EF42-AEC1-472F-B7A4-D5BEAE0C5C4C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170124160720.GB36955@elstar.local> Date: Wed, 25 Jan 2017 10:52:08 -0500 Message-Id: <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:52:14 -0000 --Apple-Mail=_04E6EF42-AEC1-472F-B7A4-D5BEAE0C5C4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juergen, Responses below. I trimmed out areas that don=E2=80=99t need a response. > On Jan 24, 2017, at 11:07 AM, Juergen Schoenwaelder = wrote: >=20 > Alissa, >=20 > thanks for your review - much appreciated. Some of the questions > indeed touch on the question 'what needs to be dealt with in an > information model and what can be left out', which I think has no > clear answer. Please see my response inline... >=20 > On Mon, Jan 23, 2017 at 02:22:25PM -0500, Alissa Cooper wrote: >=20 >> =3D Section 3.2 =3D >>=20 >> I think it would be good to provide some guidance about how NOT to = construct a group ID. E.g., I would assume putting sensitive information = like "low-income neighborhood" or similar in the group ID would be = ill-advised, because even within the single administrative domain where = MAs are communicating with Controllers and Collectors, there may be = people who are authorized to process the measurement data but not know = that level of detail about which kind of group a device/connection = belongs to. In that kind of case a mapping between an opaque identifier = in the group ID and more contextual information on the = Controller/Collector back-end would be wise. I think the draft would = benefit from some explanation of that here or in Section 6 with a = cross-reference back to here. >=20 > I agree. And I think this is not only relevant for group IDs but = equally > applies to tags or other names that can be freely choosen. What about = this > at the end of the Security Considerations: >=20 > [...] In addition, users of this Information Model are > advised to choose identifiers for Group IDs, tags or names of > information model objects (e.g., configured tasks, schedules or > actions) that do not reveal any sensitive information to people > authorized to process measurement results but who are not authorized > to know details about the Measurement Agents that were used to > perform the measurement. Sounds good.=20 >=20 >> =3D Section 3.5.2 =3D >>=20 >> What would be the cause for defining different versions of the same = task? Also, since the two different versions would have the same name = (presumably), I think you need to state of the expected scope of = uniqueness of the task name. >>=20 >=20 > Names of objects are generally assumed to be unique within an MA. I think it=E2=80=99s worth saying that explicitly. >=20 > The version here is essentially used to be able to distinguish > different versions of an implementation of a given metric. I might > have MAs with an old version of a metric implementation with specific > bugs and I might have MAs with a new version of a metric > implementation with different kind of bugs. Is there a reason that level of detail is needed on a metric-by-metric = basis, as opposed to just using a software version number for the = implementation as a whole? >=20 >> =3D Section 3.5.3 =3D >>=20 >> Why does this object need both an agent ID and a device ID? Is the = device ID here expected to be the same as the one that gets = pre-configured on the device? What is an MA supposed to put in the = device-id field defined here if there was no device ID pre-configured = (since in pre-configuration it's an optional field)? >=20 > We could make the ma-status-device-id optional to be consistent. That sounds better but I still think you need to justify it being there, = even as optional. Up to this point I thought the device ID was used = potentially to generate an agent ID during configuration, but after that = it seems to create unnecessary risk to include it in status reports. >=20 >=20 >> =3D Section 3.9 and 3.9.1 =3D >>=20 >> "Both measurement and non-measurement >> Tasks have registry entries to enable the MA to uniquely identify = the >> Task it should execute and retrieve the schema for any parameters >> that may be passed to the Task. >> ... >> A configured task can be referenced by its name and it >> contains a set of URIs to link to registry entries or a local >> specification of the task. >> ... >> ma-task-functions: A possibly empty unordered set of registry >> entries identifying the functions of the >> configured task." >>=20 >> I have a couple of questions about this: >>=20 >> (1) Are there any registries being defined for non-measurement tasks, = or is this just indicating that such registries could be created? I = think it would help to clarify since there is obviously the metrics = registry for measurement tasks. >=20 > Creating an LMAP task registry was briefly discussed on the mailing > list but so far no concrete proposal has been written. I think the > definition in section 3.9 is actually fine since it does not refer > explicitely to the IPPM metrics registry. I think it would help if it said "Both measurement and non-measurement = Tasks may have registry entries =E2=80=A6." >=20 >> (2) I don't understand "or a local specification of the task." Is = that local specification supposed to be represented with a local URI, = the same as other registry objects? Or if not, is ma-task-functions not = properly defined, since it's possible to reference something other than = a registry entry there? >=20 > The set of referenced regristry entry entries can be empty. The phrase > 'or a local specification of the task' is indeed confusing. What is > meant here is a task that is essentially well-known by its name. For > example, there is a task called 'traceroute' or 'iperf' and I expect > it to do a traceroute or to run iperf measurements. Perhaps the text > should be changed to read: >=20 > A configured task can be referenced by its name and it > contains a possibly empty set of URIs to link to registry entries. That would help, yes. >=20 >> =3D Section 3.10.1 =3D >>=20 >> I don't understand why ma-registry-role is defined here. In = draft-ietf-ippm-metric-registry, the role is part of the registry entry, = so by specifying the URI, one should know which role is the appropriate = one for that entry.=20 >>=20 >=20 > An entry in the metrics registry may define multiple roles. The > ma-registry-role selects which of these roles are instantiated. Got it, ok. >=20 >> Nits and minor comments: >=20 >> =3D Section 3 =3D >>=20 >> (1) s/(from a measurement to reporting or communicating with the = Controller)/(including measurements or reporting or communicating with = the Controller)/ >=20 > fixed >=20 >> (2) It seems a bit odd that Action first appears in Figure 1 but is = not included in the enumerated list of objects above it. >=20 > I agree - Actions came in later and it still shows. I will see what I > can do to reword this. What about this: >=20 >> (3) "Every Action contained in a Schedule is defined as a Task. ... = Tasks can implement a variety of different types of Actions." I think = this will be confusing to readers because it's circular. It sounds like = all Actions are Tasks but Tasks are comprised of Actions; I think the = abstraction needs to be explained better, and made consistent. See also = sections 3.3 and 3.7: "An Action is a Task with additional specific = parameters." I think it would be better to define what an Action is once = at its earliest use. >=20 > What about this (right below Figure 1): >=20 > The primary function of an MA is to execute Schedules. A Schedule, > which is triggered by an Event, executes a number of Actions. An > Action refers to a Configured Task and it may feed results to a > Destination Schedule. Both, Actions and Configured Tasks can = provide > parameters, represented as Action Options and Task Options. Some minor tweaks: The primary function of an MA is to execute Schedules. A Schedule, which is triggered by an Event, executes a number of Actions. An Action is a Configured Task and it may feed results to a Destination Schedule. Both Actions and Configured Tasks can provide parameters, represented as Action Options and Task Options. >=20 >> =3D Section 3.6.2 =3D >>=20 >> I think it would be good to provide a short explanation in the text = as to why RFC 3339 format is not being used for = ma-report-result-cycle-number. >=20 > The point is that the cycle-number is a fixed-point _number_. Ok, fair enough. >=20 > To address the questions (above) concerning the semantics of several > base types we have used, I think it makes sense to add the following > to section 2: >=20 > The object definitions use a couple of base types that are defined = as > follows: >=20 > int A type representing signed or unsigned integer numbers. > This information model does not define a precision nor > does it make a distinction between signed and unsigned > number ranges. This type is also used to represent > enumerations. >=20 > boolean A type representing a boolean value. >=20 > string A type representing a human-readable strings consisting > of a (possibly restricted) subset of Unicode and ISO/IEC > 10646 [ISO.10646] characters. s/strings/string/ >=20 > datetime A type representing a date and time using the Gregorian > calendar. The datetime format MUST conform to RFC 3339 > [RFC3339]. >=20 > uuid A type representing Universally Unique IDentifier (UUID( > as defined in RFC 4122 [RFC4122]. The UUID values are > expected to be unique within an installation of a large- > scale measurement system. >=20 > uri A type representing a Uniform Resource Identifier as > defined in STD 66 [RFC3986]. >=20 > ip-address A type representing an IP address. This type supports > both IPv4 and IPv6 addresses. >=20 > counter A non-negative integer that monotonically increases. > Counters may have discontinuities and they are not > expected to persist across restarts. >=20 > credentials An opaque type representing credentials needed by a > cryptographic mechanism to security communication. =20 s/security/secure/ Thanks, Alissa --Apple-Mail=_04E6EF42-AEC1-472F-B7A4-D5BEAE0C5C4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Juergen,

Responses below. I trimmed out areas = that don=E2=80=99t need a response.

On Jan 24, 2017, at 11:07 AM, = Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Alissa,

thanks for your review - much appreciated. Some = of the questions
indeed touch on the question 'what needs to be = dealt with in an
information model and what can be left out', = which I think has no
clear answer. Please see my response = inline...

On Mon, Jan 23, = 2017 at 02:22:25PM -0500, Alissa Cooper wrote:

=3D Section 3.2 =3D

I think it would be good to provide some = guidance about how NOT to construct a group ID. E.g., I would assume = putting sensitive information like "low-income neighborhood" or similar = in the group ID would be ill-advised, because even within the single = administrative domain where MAs are communicating with Controllers and = Collectors, there may be people who are authorized to process the = measurement data but not know that level of detail about which kind of = group a device/connection belongs to. In that kind of case a mapping = between an opaque identifier in the group ID and more contextual = information on the Controller/Collector back-end would be wise. I think = the draft would benefit from some explanation of that here or in Section = 6 with a cross-reference back to here.

I agree. And I = think this is not only relevant for group IDs but equally
applies to tags or = other names that can be freely choosen. What about this
at the end of the = Security Considerations:

  [...] In addition, users of this = Information Model are
  advised to choose identifiers = for Group IDs, tags or names of
  information model objects = (e.g., configured tasks, schedules or
  actions) that do not reveal = any sensitive information to people
  authorized to process = measurement results but who are not authorized
  to know = details about the Measurement Agents that were used to
  perform = the measurement.

Sounds = good. 


=3D = Section 3.5.2 =3D

What would be the cause = for defining different versions of the same task? Also, since the two = different versions would have the same name (presumably), I think you = need to state of the expected scope of uniqueness of the task name.


Names of objects are generally assumed to = be unique within an MA.

I think = it=E2=80=99s worth saying that explicitly.


The version here is essentially used to = be able to distinguish
different versions of an implementation = of a given metric. I might
have MAs with an old version of a metric = implementation with specific
bugs and I might have MAs with a new = version of a metric
implementation with different kind of = bugs.

Is there a = reason that level of detail is needed on a metric-by-metric basis, as = opposed to just using a software version number for the implementation = as a whole?


=3D = Section 3.5.3 =3D

Why does this object need = both an agent ID and a device ID? Is the device ID here expected to be = the same as the one that gets pre-configured on the device? What is an = MA supposed to put in the device-id field defined here if there was no = device ID pre-configured (since in pre-configuration it's an optional = field)?

We could make the ma-status-device-id = optional to be consistent.

That sounds = better but I still think you need to justify it being there, even as = optional. Up to this point I thought the device ID was used potentially = to generate an agent ID during configuration, but after that it seems to = create unnecessary risk to include it in status reports.



=3D Section 3.9 and 3.9.1 =3D

"Both measurement and non-measurement
  Tasks have registry entries to enable the MA to = uniquely identify the
  Task it should execute = and retrieve the schema for any parameters
  that = may be passed to the Task.
  ...
A = configured task can be referenced by its name and it
  contains a set of URIs to link to registry = entries or a local
  specification of the = task.
  ...
ma-task-functions: =        A possibly empty unordered set = of registry
          &nb= sp;            = ;     entries identifying the functions of = the
          &nb= sp;            = ;     configured task."

I have a couple of questions about this:

(1) Are there any registries being defined for = non-measurement tasks, or is this just indicating that such registries = could be created? I think it would help to clarify since there is = obviously the metrics registry for measurement tasks.

Creating an LMAP task registry was briefly = discussed on the mailing
list but so far no concrete proposal has = been written. I think the
definition in section 3.9 is actually = fine since it does not refer
explicitely to the IPPM metrics = registry.

I think it would help if it said "Both = measurement and non-measurement Tasks may have registry entries = =E2=80=A6."



(2) I don't understand "or a = local specification of the task." Is that local specification supposed = to be represented with a local URI, the same as other registry objects? = Or if not, is ma-task-functions not properly defined, since it's = possible to reference something other than a registry entry there?

The set of referenced regristry entry entries = can be empty. The phrase
'or a local specification of the task' is = indeed confusing. What is
meant here is a task that is essentially = well-known by its name. For
example, there is a task called = 'traceroute' or 'iperf' and I expect
it to do a traceroute or to run iperf = measurements. Perhaps the text
should be changed to read:

  A configured task can be = referenced by its name and it
  contains a possibly empty set = of URIs to link to registry entries.

That = would help, yes.


=3D Section 3.10.1 =3D

I don't = understand why ma-registry-role is defined here. In = draft-ietf-ippm-metric-registry, the role is part of the registry entry, = so by specifying the URI, one should know which role is the appropriate = one for that entry. 


An entry in the metrics registry may = define multiple roles. The
ma-registry-role selects which of these = roles are instantiated.

Got it, = ok.


Nits and = minor comments:

=3D Section 3 =3D

(1) = s/(from a measurement to reporting or communicating with the = Controller)/(including measurements or reporting or communicating with = the Controller)/

fixed

(2) It = seems a bit odd that Action first appears in Figure 1 but is not = included in the enumerated list of objects above it.

I agree - Actions came in later and it still = shows. I will see what I
can do to reword this. What about = this:

(3) "Every Action contained = in a Schedule is defined as a Task. ... Tasks can implement a variety of = different types of Actions." I think this will be confusing to readers = because it's circular. It sounds like all Actions are Tasks but Tasks = are comprised of Actions; I think the abstraction needs to be explained = better, and made consistent. See also sections 3.3 and 3.7: "An Action = is a Task with additional specific parameters." I think it would be = better to define what an Action is once at its earliest use.

What about this (right below Figure = 1):

  The = primary function of an MA is to execute Schedules.  A = Schedule,
  which is triggered by an Event, = executes a number of Actions.  An
  Action refers to a Configured = Task and it may feed results to a
  Destination Schedule. =  Both, Actions and Configured Tasks can provide
  parameters, represented as Action Options and = Task Options.

Some minor = tweaks:

The = primary function of an MA is to execute Schedules.  A = Schedule,
  which is triggered by an Event, = executes a number of Actions.  An
  Action is a Configured Task and it may feed = results to a
  Destination Schedule. =  Both Actions and Configured Tasks can provide
  parameters, represented as Action Options and = Task Options.


=3D Section 3.6.2 =3D

I think it = would be good to provide a short explanation in the text as to why RFC = 3339 format is not being used for ma-report-result-cycle-number.

The point is that the cycle-number is a = fixed-point _number_.

Ok, fair = enough.


To address the questions (above) concerning the = semantics of several
base types we have used, I think it makes = sense to add the following
to section 2:

  The object definitions use a = couple of base types that are defined as
  follows:

  int =         A type representing = signed or unsigned integer numbers.
          &nb= sp;   This information model does not define a precision = nor
          &nb= sp;   does it make a distinction between signed and = unsigned
          &nb= sp;   number ranges.  This type is also used to = represent
          &nb= sp;   enumerations.

  boolean     A = type representing a boolean value.

  string =      A type representing a human-readable = strings consisting
          &nb= sp;   of a (possibly restricted) subset of Unicode and = ISO/IEC
      = ; 10646 [ISO.10646] characters.

s/strings/string/


  datetime    A = type representing a date and time using the Gregorian
          &nb= sp;   calendar.  The datetime format MUST conform to = RFC 3339
          &nb= sp;   [RFC3339].

  uuid =        A type representing = Universally Unique IDentifier (UUID(
          &nb= sp;   as defined in RFC 4122 [RFC4122].  The UUID = values are
          &nb= sp;   expected to be unique within an installation of a = large-
          &nb= sp;   scale measurement system.

  uri =         A type representing a = Uniform Resource Identifier as
          &nb= sp;   defined in STD 66 [RFC3986].

  ip-address  A type = representing an IP address.  This type supports
          &nb= sp;   both IPv4 and IPv6 addresses.

  counter =     A non-negative integer that monotonically = increases.
      = ; Counters may have discontinuities and they are not
      = ; expected to persist across restarts.

  credentials An opaque type = representing credentials needed by a
          &nb= sp;   cryptographic mechanism to security communication. =  

s/security/secure/

Thanks,
Alissa


= --Apple-Mail=_04E6EF42-AEC1-472F-B7A4-D5BEAE0C5C4C-- From nobody Wed Jan 25 07:57:25 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABE41299A8 for ; Wed, 25 Jan 2017 07:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=2YunXeiM; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=lQkTteLr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg8EJwDu2iYm for ; Wed, 25 Jan 2017 07:57:21 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9B91299A7 for ; Wed, 25 Jan 2017 07:57:21 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9829C20799; Wed, 25 Jan 2017 10:57:20 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 25 Jan 2017 10:57:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=aK3NzK22SUXT05S /dayMVUQ5L4M=; b=2YunXeiMLLI5KNcs+KVx4HL+t4bhtvitzj3yRjovYxRnUD4 g3OFJic9W7nl+NiZTS6JP/+EUb8zhAoLJaM9FdFNsY+xXPJmlMyaUBtcy5bG8zjQ HvWJ4Z/5dnyXvzH8V2+UXUsAsx+VddXzF8Fgyl+2XNT447HOmq4uAM1ZMi30= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=aK3NzK22SUXT05S/dayMVUQ5L4M=; b=lQkTteLrwZPTDdwewyU0 4ErmsfQABbuf7Jnqzfy7WKwvqcpKXs8Nx4IPTbYpw1I/22i74CT0Ev8ROQdbie4X cnoxla8C01N97foivE49UuLbPWYHqn4LWPTYXWdXq6z81GMIOlGl5SB9/p2M/7H2 Y3B8vnKIlE/PKcF9JSbrpgw= X-ME-Sender: X-Sasl-enc: Igii0mObjMCgGJis6opYcUjvbmUkCd60qsDo4BG5LJig 1485359840 Received: from dhcp-10-150-9-181.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 431127E34F; Wed, 25 Jan 2017 10:57:20 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170125091835.GB40411@elstar.jacobs.jacobs-university.de> Date: Wed, 25 Jan 2017 10:57:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> <20170124202801.GB38068@elstar.local> <248d21f7ec4546b0af1fe98e604a4c8e@rew09926dag03c.domain1.systemhost.net> <20170125091835.GB40411@elstar.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:57:23 -0000 Juergen, > On Jan 25, 2017, at 4:18 AM, Juergen Schoenwaelder = wrote: >=20 > Trevor, >=20 > this is also the explanation I came up with but the document does not > really explain this. Alissa, would this resolve your comment if I try > to add text that tries to explain this distinction? Would it help to > add examples? Explanation and examples would help, especially if some clear = delineation about what belongs in each credential set can be given, = albeit while remaining generic. But the bigger question is ... >=20 > - SSH host keys are I think examples of MA credentials while SSH user > authentication keys and authorization lists are channel > credentials. >=20 > - X.509 certificates defining trust to X.509 root authorities are > examples of MA credentials. while X.509 client ceritifcates for TLS > communication are channel credentials. =E2=80=A6 can you explain why you want the controller to be able to = change each of these on the MA, from how they were pre-configured? Thanks, Alissa >=20 > (Lets see whether I got this right. ;-) >=20 > /js >=20 > On Wed, Jan 25, 2017 at 09:02:11AM +0000, trevor.burbridge@bt.com = wrote: >> Initially the MA credentials were the private credentials of the MA = and the channel credentials were the public credentials for each channel = end-point. >>=20 >> Trevor. >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 >> Sent: 24 January 2017 20:28 >> To: Burbridge,T,Trevor,TUB8 R ; = Eardley,PL,Philip,TUB8 R >> Cc: lmap@ietf.org; Alissa Cooper >> Subject: Re: [lmap] AD evaluation: = draft-ietf-lmap-information-model-16 >>=20 >> Trevor and Phil, >>=20 >> do you recall the reason why we have channel credentials and MA = global credentials? How are the MA global credentials supposed to be = used? >>=20 >> /js >>=20 >> On Tue, Jan 24, 2017 at 11:03:11AM -0500, Alissa Cooper wrote: >>>=20 >>>> On Jan 23, 2017, at 2:22 PM, Alissa Cooper = wrote: >>>>=20 >>>> (2) Are ma-preconfig-credentials and ma-config-credentials meant to = be credentials only for the MA to be authenticated by a Controller or = Collector? I assume that the credentials that allow the MA to = authenticate other endpoints, and to protect communications to those = endpoints, are stored in ma-channel-credentials, but it would help to = clarify which set of credentials each of these fields is referring to. >>>=20 >>> Just to reinforce this, now that I=E2=80=99m doing a review of = draft-ietf-lmap-yang: it seems that the model in = draft-ietf-netconf-netconf-client-server defines both the client and = server credentials. So if that is supposed to fulfill the channel = credentials in the information model, what happens if the = ma-config-credentials for the MA are different than the ones in the = ma-channel-obj for the MA? Which ones is the MA supposed to use? >>>=20 >>> Thanks, >>> Alissa >>> _______________________________________________ >>> lmap mailing list >>> lmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/lmap >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Jan 25 10:25:32 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B503A129AC0 for ; Wed, 25 Jan 2017 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=h4C+aFLA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=huyYCDoA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is5gQzwP9mgU for ; Wed, 25 Jan 2017 10:25:28 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3F5129AC9 for ; Wed, 25 Jan 2017 10:25:28 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1B6FE209C4; Wed, 25 Jan 2017 13:25:28 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 25 Jan 2017 13:25:28 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=WnlLnpaa7QRiX45 /MutKTvsq5vw=; b=h4C+aFLAsUZ/Naa3V0NBqcyf4A7GRjanwUaH7sJ9zDxKYL9 qL4yrJvs4n6DAAjnl2XzI/teA3DR8h1XS2HPhnuUxsqHOP36dm0jm/Qpl0sFN+2Q vPl37PcyaWSGl8hfLETaNBWve7yuPCDK1aOsnOg1WMDK92JLFbAdb4VVQOIg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=WnlLnpaa7QRiX45/MutKTvsq5vw=; b=huyYCDoAxR3afd+l9hi2 Lt8ZkS5ykVeD0Y7zE2Cy1yr4otgC4v79d2EErZQ1F82YwUMsVIlETkI2Tz42ukAJ 1NW0tD0xvl/aiUj3Nhf4/syXskST4fRn/2VRUW9M5GfUqvDyp/U8k1FpGPAw45Sx yxevednN0QUwWaqGRntrsqU= X-ME-Sender: X-Sasl-enc: 2vqrIg4fiG61Xj/TVZE7STuP1UezFKYmx5RFqBoklLZw 1485368727 Received: from dhcp-10-150-9-181.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 5443F7E2DA; Wed, 25 Jan 2017 13:25:27 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170124202305.GA38068@elstar.local> Date: Wed, 25 Jan 2017 13:25:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:25:31 -0000 Hi Juergen, Responses below. I trimmed out areas that don=E2=80=99t need a response. > On Jan 24, 2017, at 3:23 PM, Juergen Schoenwaelder = wrote: >=20 >> =3D Section 4.2 =3D >>=20 >> (1) "It is generally a good idea to always configure >> an end time and to refresh the configuration >> of event object as needed to ensure that agents >> that loose connectivity to their controller >> do not continue their tasks forever." >>=20 >> This is more of a comment for the information model, but if this is = worth saying here, shouldn't it (also) be mentioned in the corresponding = information model definition in draft-ietf-lmap-information-model? This = doesn't seem specific to this particular data model. >=20 > I see your point. I think it makes sense to note this in the second > item 4. of section 3 of the information model. (I will change the > numbering of the second list to use letters to make it easier to refer > to things.) >=20 > [...] For Event objects specifying a > series of events, it is generally a good idea to configure an = end > time and to refresh the end time as needed to ensure that MAs > that loose connectivity to their controller do not continue > executing Schedules forever. Sounds good. >=20 >> (2) For all the counters defined here, I think you need to specify = the time period over which the counts are to be calculated. >=20 > We use counters as defined in RFC 6991 and I think the definition in > RFC 6991 takes care of things. Ok. >=20 >> (3) 'list action { >> key name; >> description >> "An action describes a task that is invoked by the >> schedule. Multiple actions are invoked = sequentially.";' >>=20 >> I don't get this -- doesn't the execution mode define whether the = actions are executed sequentially, in parallel, or pipelined? >=20 > Good catch. Changed this to: >=20 > list action { > key name; > description > "An action describes a task that is invoked by the > schedule. Multiple actions are invoked according to > the execution-mode of the schedule.=E2=80=9D; Sounds good. >=20 >> (4) "A queue is internally used to pass >> results to another schedule." >>=20 >> I thought it was up to the implementation to decide how to implement = this? >=20 > OK. I meanwhile understand that the word 'queue' has too many > connotations. Is 'buffer' a less problematic term? The key here is > that the data producer and the data consumer are in general not > running at the time and hence data needs to be stored temporarily > somewhere. Isn=E2=80=99t this implied though? Even with =E2=80=9Cbuffer=E2=80=9D it = still seems like specifying an implementation detail. I=E2=80=99d prefer = to see something like your last sentence above instead. > I will replace queue with buffer for now. >=20 >> (5) I don't understand why the 'program' elements are included in the = task configurations and capabilities. It doesn't seem wise to allow the = controller to tell the MA which program it needs to use to complete a = task, and I don't understand why the MA would need to communicate that = information to the controller either. I thought the recent list = discussion indicated that if an MA was not capable of performing an = action, that action would simply fail, which seems like all that is = needed. >=20 > There are multiple things: >=20 > (a) How do I tell which task I want to have executed? The information > model assumes that this can be done with the help of a registry. > The YANG data model, in addition, allows to use a simple 'program > name'. Note that this is a choice, i.e., you either use a registry > or a program name, but not both. >=20 > The registry at the end is just some level of indirection - but > this indirection also requires to have tasks registered in a > registry. Right now, the implementation I know of only supports > program names. >=20 > (b) The task list in the capabilities branch serves as an inventory, > i.e., it tells the controller which tasks are supported by a given > implementation. The other task list defined options that are used > when a certain task is invoked (the Task Configuration in the > information model). If a controller configures a task that the > agent does support (i.e., it is not listed in the capability > tasks), it will not be executed. >=20 > Note that a capability task name 'traceroute' exposed by the LMAP > agent does not necessarily mean that there is a program called > traceroute at the operating system level. In fact, an implementation > could choose to run traceroute internally without an explicit system > level process (like RIPE Atlas did everything in a big event loop, not > sure whether this is still the case). Ok, I can understand that under circumstances where there is no = registry, there needs to be some identifier to indicate which task to = run, and which tasks the MA is capable of running. But the examples seem = to imply that =E2=80=98program=E2=80=99 is the path and file name of the = actual executable on the MA, which is what seems dangerous and = unnecessary to me. Why would the controller necessarily even know where = such executables reside on the file system? And I know there are a lot = of things that could go wrong if a Controller gets compromised, but it = just seems like making it so trivial for an MA implementation to = literally just run the executable name specified by the Controller = creates unnecessary risk. If the task name on its own is not sufficient for the MA to be able to = figure out which program is suitable to run, why not have the additional = field defined as =E2=80=98program-name=E2=80=99 with some guidance about = how to populate it, so that, e.g., what you end up with in that field is = =E2=80=9Cmtr=E2=80=9D or =E2=80=9Cfping=E2=80=9D instead of = "/usr/bin/mtr=E2=80=9D or "/usr/bin/fping=E2=80=9D? >=20 >> Nits and minor comments: >=20 >> (2) "Implementers MUST taken care that >> option names and values are passed literally to programs. In >> particular, it MUST be avoided that any shell expansions are >> performed that may alter the option names and values." >>=20 >> This text strikes me as a bit odd. Surely there are a whole selection = of good programming practices that are necessary to ensure that things = don't go haywire when implementing LMAP -- why call out these two with = normative recommendations? Why does this guidance only apply to options? = I would recommend having this text be non-normative, but if you do keep = it I would suggest the following: >>=20 >> Implementers MUST take care that >> option names and values are passed literally to programs. In >> particular, shell expansions that may alter the option names and = values MUST NOT be performed. >=20 > I have no strong opinion on MUST vs must here and I usually happily > follow the advice of IESG members on RFC 2119 keywords. ;-) Ok, my suggestion is to use non-normative =E2=80=9Cought to=E2=80=9D = rather than 2119 MUST. Thanks, Alissa >=20 > Yes, there are many ways to write broken code but this is such a > common problem that I think can't hurt to remind implementors. >=20 > A diff of -10 to my working copy (of -11) can be found here: >=20 > http://beadg.de/lmap/ >=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 From nobody Thu Jan 26 00:54:02 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EDF1294FD for ; Thu, 26 Jan 2017 00:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMvRJcESh_-I for ; Thu, 26 Jan 2017 00:53:54 -0800 (PST) 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 59E7C1294F8 for ; Thu, 26 Jan 2017 00:53:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 22D4D711; Thu, 26 Jan 2017 09:53:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U9D4E5eNshSC; Thu, 26 Jan 2017 09:53:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jan 2017 09:53:52 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FDC0200AC; Thu, 26 Jan 2017 09:53:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m2vnYJOkiFkw; Thu, 26 Jan 2017 09:53:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3A4A200AB; Thu, 26 Jan 2017 09:53:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BBA3A3E4CB5A; Thu, 26 Jan 2017 09:53:54 +0100 (CET) Date: Thu, 26 Jan 2017 09:53:54 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170126085354.GA43055@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> 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: <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 08:53:57 -0000 On Wed, Jan 25, 2017 at 10:52:08AM -0500, Alissa Cooper wrote: > Hi Juergen, > > Responses below. I trimmed out areas that don’t need a response. > Trimming even further... > > The version here is essentially used to be able to distinguish > > different versions of an implementation of a given metric. I might > > have MAs with an old version of a metric implementation with specific > > bugs and I might have MAs with a new version of a metric > > implementation with different kind of bugs. > > Is there a reason that level of detail is needed on a metric-by-metric basis, as opposed to just using a software version number for the implementation as a whole? You can have monolithic or modular implementations. In a modular implementation, the version of a metric implementation may change without the change of the version of the MA. People with measurement experience have often stated how important it is to know precisely which version of software was involved in a measurement since this often is essential to understand artifacts observed during data analysis. > >> = Section 3.5.3 = > >> > >> Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the device-id field defined here if there was no device ID pre-configured (since in pre-configuration it's an optional field)? > > > > We could make the ma-status-device-id optional to be consistent. > > That sounds better but I still think you need to justify it being there, even as optional. Up to this point I thought the device ID was used potentially to generate an agent ID during configuration, but after that it seems to create unnecessary risk to include it in status reports. What kind of risks? The device-id is one piece of information that may be used by a controller while assigning an agent-id. So it is exposed to a controller anyway. And the model does not make any statement that an agent-id can only assigned during an initial bootstrap process, i.e., a controller may have reasons to re-bootstrap (is that a word?) the LMAP agent. > > > >> = Section 3.9 and 3.9.1 = > >> > >> "Both measurement and non-measurement > >> Tasks have registry entries to enable the MA to uniquely identify the > >> Task it should execute and retrieve the schema for any parameters > >> that may be passed to the Task. > >> ... > >> A configured task can be referenced by its name and it > >> contains a set of URIs to link to registry entries or a local > >> specification of the task. > >> ... > >> ma-task-functions: A possibly empty unordered set of registry > >> entries identifying the functions of the > >> configured task." > >> > >> I have a couple of questions about this: > >> > >> (1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the metrics registry for measurement tasks. > > > > Creating an LMAP task registry was briefly discussed on the mailing > > list but so far no concrete proposal has been written. I think the > > definition in section 3.9 is actually fine since it does not refer > > explicitely to the IPPM metrics registry. > > I think it would help if it said "Both measurement and non-measurement Tasks may have registry entries …." > You want me to repeat this sentence [...] Both measurement and non-measurement Tasks have registry entries to enable the MA to uniquely identify the Task it should execute and retrieve the schema for any parameters that may be passed to the Task. that is already in section 3.9 in the description of ma-task-functions (section 3.9.1)? > > What about this (right below Figure 1): > > > > The primary function of an MA is to execute Schedules. A Schedule, > > which is triggered by an Event, executes a number of Actions. An > > Action refers to a Configured Task and it may feed results to a > > Destination Schedule. Both, Actions and Configured Tasks can provide > > parameters, represented as Action Options and Task Options. > > Some minor tweaks: > > The primary function of an MA is to execute Schedules. A Schedule, > which is triggered by an Event, executes a number of Actions. An > Action is a Configured Task and it may feed results to a > Destination Schedule. Both Actions and Configured Tasks can provide > parameters, represented as Action Options and Task Options. Well, an Action refers to a Configured Task, I do not think it is correct to say an Action is a Configured Task. I think the text I proposed is more precise. > > string A type representing a human-readable strings consisting > > of a (possibly restricted) subset of Unicode and ISO/IEC > > 10646 [ISO.10646] characters. > > s/strings/string/ fixed > > credentials An opaque type representing credentials needed by a > > cryptographic mechanism to security communication. > > s/security/secure/ fixed /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 Jan 26 01:52:26 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2359129509 for ; Thu, 26 Jan 2017 01:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDQv-ZVdzrr0 for ; Thu, 26 Jan 2017 01:52:23 -0800 (PST) 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 0B684129502 for ; Thu, 26 Jan 2017 01:52:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C7C2D7F4; Thu, 26 Jan 2017 10:52:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id q532xmMcHQAa; Thu, 26 Jan 2017 10:52:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jan 2017 10:52:20 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 582A4200AC; Thu, 26 Jan 2017 10:52:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i3A8g_QLCGwq; Thu, 26 Jan 2017 10:52:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 114AF200AB; Thu, 26 Jan 2017 10:52:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 073133E4CD5D; Thu, 26 Jan 2017 10:52:21 +0100 (CET) Date: Thu, 26 Jan 2017 10:52:21 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170126095221.GC43055@elstar.local> Mail-Followup-To: Alissa Cooper , trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <22680E7F-38D2-46FE-8549-CBB783ECAF32@cooperw.in> <20170124202801.GB38068@elstar.local> <248d21f7ec4546b0af1fe98e604a4c8e@rew09926dag03c.domain1.systemhost.net> <20170125091835.GB40411@elstar.jacobs.jacobs-university.de> 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.6.0 (2016-04-01) Archived-At: Cc: trevor.burbridge@bt.com, philip.eardley@bt.com, lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 09:52:25 -0000 On Wed, Jan 25, 2017 at 10:57:19AM -0500, Alissa Cooper wrote: > Juergen, > > > On Jan 25, 2017, at 4:18 AM, Juergen Schoenwaelder wrote: > > > > Trevor, > > > > this is also the explanation I came up with but the document does not > > really explain this. Alissa, would this resolve your comment if I try > > to add text that tries to explain this distinction? Would it help to > > add examples? > > Explanation and examples would help, especially if some clear delineation about what belongs in each credential set can be given, albeit while remaining generic. But the bigger question is ... > > > > > - SSH host keys are I think examples of MA credentials while SSH user > > authentication keys and authorization lists are channel > > credentials. > > > > - X.509 certificates defining trust to X.509 root authorities are > > examples of MA credentials. while X.509 client ceritifcates for TLS > > communication are channel credentials. > > … can you explain why you want the controller to be able to change each of these on the MA, from how they were pre-configured? > I will try to write some text. Here is the story line: The channel credentials are relatively obvious (I think) since (i) credentials often have an expire time (e.g., valid until in X.509 certificates) and (ii) a controller may want to push channel credentials that are necessary to talk to a collector or a different controller - i.e., an initial bootstrap controller may want to redirect a device to another controller taking care of the device subsequently. If you think about this, then it may indeed be necessary to update MA credentials as well in order to allow the MA to verify the credentials presented by a collector or a different controller. For an MA embedded in a more complex system, the management of the credentials may not be controller specific or it may be done entirely by a different component. In the YANG models, the LMAP model does not deal with credential management at all. Instead, credentials are deal with with the NETCONF/RESTCONF data models. And they again refer to security protocol specific models (for SSH and TLS) and these again refer to a keystore data model. All this is relatively complex and all the LMAP information models says is that the functionality to manage credentials is needed - but it leaves it opaque. Do you think it is wrong to say that an LMAP controller may need to update channel and MA credentials in the information model? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 26 02:17:10 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD93129512 for ; Thu, 26 Jan 2017 02:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhO_vJgYMkio for ; Thu, 26 Jan 2017 02:17:07 -0800 (PST) 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 27F4A129448 for ; Thu, 26 Jan 2017 02:17:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DAB447BD; Thu, 26 Jan 2017 11:17:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LWjg2lDP_vtr; Thu, 26 Jan 2017 11:17:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Jan 2017 11:17:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F40B200AC; Thu, 26 Jan 2017 11:17:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J9Z2aUrM8p34; Thu, 26 Jan 2017 11:17:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EAAE200AB; Thu, 26 Jan 2017 11:17:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C72823E4CDFF; Thu, 26 Jan 2017 11:17:06 +0100 (CET) Date: Thu, 26 Jan 2017 11:17:06 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170126101706.GD43055@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <49AB42C1-3DE5-4289-9B32-173B69C191DC@cooperw.in> <20170124202305.GA38068@elstar.local> 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.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-yang-10 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 10:17:09 -0000 Trimming things down... On Wed, Jan 25, 2017 at 01:25:26PM -0500, Alissa Cooper wrote: > > > >> (4) "A queue is internally used to pass > >> results to another schedule." > >> > >> I thought it was up to the implementation to decide how to implement this? > > > > OK. I meanwhile understand that the word 'queue' has too many > > connotations. Is 'buffer' a less problematic term? The key here is > > that the data producer and the data consumer are in general not > > running at the time and hence data needs to be stored temporarily > > somewhere. > > Isn’t this implied though? Even with “buffer” it still seems like specifying an implementation detail. I’d prefer to see something like your last sentence above instead. So I will replace 'buffer' with 'somewhere'. Oh boy. Here is the new text: A set of schedules receiving the output produced by this action. The output is stored temporarily somewhere since the destination schedules will in general not be running when output is passed to them. The behaviour of an action passing data to its own schedule is implementation specific. > > I will replace queue with buffer for now. > > > >> (5) I don't understand why the 'program' elements are included in the task configurations and capabilities. It doesn't seem wise to allow the controller to tell the MA which program it needs to use to complete a task, and I don't understand why the MA would need to communicate that information to the controller either. I thought the recent list discussion indicated that if an MA was not capable of performing an action, that action would simply fail, which seems like all that is needed. > > > > There are multiple things: > > > > (a) How do I tell which task I want to have executed? The information > > model assumes that this can be done with the help of a registry. > > The YANG data model, in addition, allows to use a simple 'program > > name'. Note that this is a choice, i.e., you either use a registry > > or a program name, but not both. > > > > The registry at the end is just some level of indirection - but > > this indirection also requires to have tasks registered in a > > registry. Right now, the implementation I know of only supports > > program names. > > > > (b) The task list in the capabilities branch serves as an inventory, > > i.e., it tells the controller which tasks are supported by a given > > implementation. The other task list defined options that are used > > when a certain task is invoked (the Task Configuration in the > > information model). If a controller configures a task that the > > agent does support (i.e., it is not listed in the capability > > tasks), it will not be executed. > > > > Note that a capability task name 'traceroute' exposed by the LMAP > > agent does not necessarily mean that there is a program called > > traceroute at the operating system level. In fact, an implementation > > could choose to run traceroute internally without an explicit system > > level process (like RIPE Atlas did everything in a big event loop, not > > sure whether this is still the case). > > Ok, I can understand that under circumstances where there is no registry, there needs to be some identifier to indicate which task to run, and which tasks the MA is capable of running. But the examples seem to imply that ‘program’ is the path and file name of the actual executable on the MA, which is what seems dangerous and unnecessary to me. I can take out the path if that helps. Why would the controller necessarily even know where such executables reside on the file system? And I know there are a lot of things that could go wrong if a Controller gets compromised, but it just seems like making it so trivial for an MA implementation to literally just run the executable name specified by the Controller creates unnecessary risk. Perhaps we need to add more explicit text to /tasks/task saying that a configured LMAP task MUST resolve to a task listed in the capabilities. This is in my view what matters most. > If the task name on its own is not sufficient for the MA to be able to figure out which program is suitable to run, why not have the additional field defined as ‘program-name’ with some guidance about how to populate it, so that, e.g., what you end up with in that field is “mtr” or “fping” instead of "/usr/bin/mtr” or "/usr/bin/fping”? I do not really see the logic here. An implementation that blindly executes a program called 'mtr' by search a search PATH may actually be worse than an implementation that executes /some/path/mtr. > >> Nits and minor comments: > > > >> (2) "Implementers MUST taken care that > >> option names and values are passed literally to programs. In > >> particular, it MUST be avoided that any shell expansions are > >> performed that may alter the option names and values." > >> > >> This text strikes me as a bit odd. Surely there are a whole selection of good programming practices that are necessary to ensure that things don't go haywire when implementing LMAP -- why call out these two with normative recommendations? Why does this guidance only apply to options? I would recommend having this text be non-normative, but if you do keep it I would suggest the following: > >> > >> Implementers MUST take care that > >> option names and values are passed literally to programs. In > >> particular, shell expansions that may alter the option names and values MUST NOT be performed. > > > > I have no strong opinion on MUST vs must here and I usually happily > > follow the advice of IESG members on RFC 2119 keywords. ;-) > > Ok, my suggestion is to use non-normative “ought to” rather than 2119 MUST. Seriously? I have left the 'must' in (there are other occurances of must) and I leave it to the discretion of the IESG to discuss this if needed - and then I do whatever comes out of 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 Mon Jan 30 07:45:13 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809E0129536 for ; Mon, 30 Jan 2017 07:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=FsRzZanm; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=f3DOuNtP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBM8RdgMAJD9 for ; Mon, 30 Jan 2017 07:45:06 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D808129530 for ; Mon, 30 Jan 2017 07:45:06 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E0768223A8; Mon, 30 Jan 2017 10:45:05 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Mon, 30 Jan 2017 10:45:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Wygx9Sls58sEpd+ J5M5QckaliOk=; b=FsRzZanm/UllXrEqH9oPChrCLvMKCmGUke9RdXewNdtIbQm wKf79fxx0GIK2qVx+JvS47hv0aeOJCt7JwYud3eD24oBmuwMKdgQVxkqocPyLJmO Qv7zn+dUslqIduIvmEVtl3GSv0QWJQT05kJRLvOtDVe1shWyIpx/KupQX2+A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=Wygx9Sls58sEpd+J5M5QckaliOk=; b=f3DOuNtPcpn7J5pMIRj+ QsYh/gbtxWCDOZHHTHg8OD5ElN+cCJ506jfLRIFMdsRNYbbFFq6HmAKMdkYaFBWt jgUBw++zPpvFImTmJFrEo+gvvngxL/wvldtahbERIvRhUQ12A8qysKnKZdZYFaPL WAgDNGp9pGEJAVQ6YfKW7qw= X-ME-Sender: X-Sasl-enc: vJCmuTSmcEJveZ/C3aoYqwjvjWLO58TUvMIpPSvXUWIM 1485791105 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E506C240CC; Mon, 30 Jan 2017 10:45:04 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170126085354.GA43055@elstar.local> Date: Mon, 30 Jan 2017 10:45:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 15:45:11 -0000 Hi Juergen, > On Jan 26, 2017, at 3:53 AM, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jan 25, 2017 at 10:52:08AM -0500, Alissa Cooper wrote: >> Hi Juergen, >>=20 >> Responses below. I trimmed out areas that don=E2=80=99t need a = response. >>=20 >=20 > Trimming even further... >=20 >>> The version here is essentially used to be able to distinguish >>> different versions of an implementation of a given metric. I might >>> have MAs with an old version of a metric implementation with = specific >>> bugs and I might have MAs with a new version of a metric >>> implementation with different kind of bugs. >>=20 >> Is there a reason that level of detail is needed on a = metric-by-metric basis, as opposed to just using a software version = number for the implementation as a whole? >=20 > You can have monolithic or modular implementations. In a modular > implementation, the version of a metric implementation may change > without the change of the version of the MA. People with measurement > experience have often stated how important it is to know precisely > which version of software was involved in a measurement since this > often is essential to understand artifacts observed during data > analysis. Ok. >=20 >>>> =3D Section 3.5.3 =3D >>>>=20 >>>> Why does this object need both an agent ID and a device ID? Is the = device ID here expected to be the same as the one that gets = pre-configured on the device? What is an MA supposed to put in the = device-id field defined here if there was no device ID pre-configured = (since in pre-configuration it's an optional field)? >>>=20 >>> We could make the ma-status-device-id optional to be consistent. >>=20 >> That sounds better but I still think you need to justify it being = there, even as optional. Up to this point I thought the device ID was = used potentially to generate an agent ID during configuration, but after = that it seems to create unnecessary risk to include it in status = reports. >=20 > What kind of risks? The device-id is one piece of information that may > be used by a controller while assigning an agent-id. So it is exposed > to a controller anyway. And the model does not make any statement that > an agent-id can only assigned during an initial bootstrap process, > i.e., a controller may have reasons to re-bootstrap (is that a word?) > the LMAP agent. Since the device ID can be an ID that is re-used in all kinds of = contexts (e.g., a MAC address), its use creates the potential to = correlate LMAP activities with other activities in which the device is = engaged, and potentially to identify the user. Again thinking about = whether there might be different access control domains *within* a = controller, it seems unnecessary to expose something like a MAC address = in a status reporting context if the MA can be uniquely identified by = the agent ID. Then only the code/people that deal with configuration = need authorization to process MAC addresses or other device IDs. >=20 >>>=20 >>>> =3D Section 3.9 and 3.9.1 =3D >>>>=20 >>>> "Both measurement and non-measurement >>>> Tasks have registry entries to enable the MA to uniquely identify = the >>>> Task it should execute and retrieve the schema for any parameters >>>> that may be passed to the Task. >>>> ... >>>> A configured task can be referenced by its name and it >>>> contains a set of URIs to link to registry entries or a local >>>> specification of the task. >>>> ... >>>> ma-task-functions: A possibly empty unordered set of = registry >>>> entries identifying the functions of the >>>> configured task." >>>>=20 >>>> I have a couple of questions about this: >>>>=20 >>>> (1) Are there any registries being defined for non-measurement = tasks, or is this just indicating that such registries could be created? = I think it would help to clarify since there is obviously the metrics = registry for measurement tasks. >>>=20 >>> Creating an LMAP task registry was briefly discussed on the mailing >>> list but so far no concrete proposal has been written. I think the >>> definition in section 3.9 is actually fine since it does not refer >>> explicitely to the IPPM metrics registry. >>=20 >> I think it would help if it said "Both measurement and = non-measurement Tasks may have registry entries =E2=80=A6." >>=20 >=20 > You want me to repeat this sentence >=20 > [...] Both measurement and non-measurement > Tasks have registry entries to enable the MA to uniquely identify = the > Task it should execute and retrieve the schema for any parameters > that may be passed to the Task. >=20 > that is already in section 3.9 in the description of ma-task-functions > (section 3.9.1)? No, sorry, I was just suggesting that you add the word =E2=80=9Cmay." >=20 >>> What about this (right below Figure 1): >>>=20 >>> The primary function of an MA is to execute Schedules. A Schedule, >>> which is triggered by an Event, executes a number of Actions. An >>> Action refers to a Configured Task and it may feed results to a >>> Destination Schedule. Both, Actions and Configured Tasks can = provide >>> parameters, represented as Action Options and Task Options. >>=20 >> Some minor tweaks: >>=20 >> The primary function of an MA is to execute Schedules. A Schedule, >> which is triggered by an Event, executes a number of Actions. An >> Action is a Configured Task and it may feed results to a >> Destination Schedule. Both Actions and Configured Tasks can provide >> parameters, represented as Action Options and Task Options. >=20 > Well, an Action refers to a Configured Task, I do not think it is > correct to say an Action is a Configured Task. Then why does the text in later sections say "An Action is a Task with = additional specific parameters=E2=80=9D? That is where I am confused. Thanks, Alissa From nobody Tue Jan 31 01:44:44 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E67129E01 for ; Tue, 31 Jan 2017 01:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DGL7bkibS58 for ; Tue, 31 Jan 2017 01:44:40 -0800 (PST) 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 AE20612943C for ; Tue, 31 Jan 2017 01:44:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C14F6C0; Tue, 31 Jan 2017 10:44:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pEu7LL1btIBt; Tue, 31 Jan 2017 10:44:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 Jan 2017 10:44:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A738200AC; Tue, 31 Jan 2017 10:44:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8kwUx7o49mGR; Tue, 31 Jan 2017 10:44:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D01E5200AB; Tue, 31 Jan 2017 10:44:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BA6063E538B3; Tue, 31 Jan 2017 10:44:27 +0100 (CET) Date: Tue, 31 Jan 2017 10:44:27 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170131094427.GA59387@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> 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: <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 09:44:42 -0000 On Mon, Jan 30, 2017 at 10:45:03AM -0500, Alissa Cooper wrote: > >>>> = Section 3.5.3 = > >>>> > >>>> Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the device-id field defined here if there was no device ID pre-configured (since in pre-configuration it's an optional field)? > >>> > >>> We could make the ma-status-device-id optional to be consistent. > >> > >> That sounds better but I still think you need to justify it being there, even as optional. Up to this point I thought the device ID was used potentially to generate an agent ID during configuration, but after that it seems to create unnecessary risk to include it in status reports. > > > > What kind of risks? The device-id is one piece of information that may > > be used by a controller while assigning an agent-id. So it is exposed > > to a controller anyway. And the model does not make any statement that > > an agent-id can only assigned during an initial bootstrap process, > > i.e., a controller may have reasons to re-bootstrap (is that a word?) > > the LMAP agent. > > Since the device ID can be an ID that is re-used in all kinds of contexts (e.g., a MAC address), its use creates the potential to correlate LMAP activities with other activities in which the device is engaged, and potentially to identify the user. Again thinking about whether there might be different access control domains *within* a controller, it seems unnecessary to expose something like a MAC address in a status reporting context if the MA can be uniquely identified by the agent ID. Then only the code/people that deal with configuration need authorization to process MAC addresses or other device IDs. > The status reports go to the LMAP controller, so I do not really see why there is a specific risk since the controller has access to the device ID anyway. > >>>> = Section 3.9 and 3.9.1 = > >>>> > >>>> "Both measurement and non-measurement > >>>> Tasks have registry entries to enable the MA to uniquely identify the > >>>> Task it should execute and retrieve the schema for any parameters > >>>> that may be passed to the Task. > >>>> ... > >>>> A configured task can be referenced by its name and it > >>>> contains a set of URIs to link to registry entries or a local > >>>> specification of the task. > >>>> ... > >>>> ma-task-functions: A possibly empty unordered set of registry > >>>> entries identifying the functions of the > >>>> configured task." > >>>> > >>>> I have a couple of questions about this: > >>>> > >>>> (1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the metrics registry for measurement tasks. > >>> > >>> Creating an LMAP task registry was briefly discussed on the mailing > >>> list but so far no concrete proposal has been written. I think the > >>> definition in section 3.9 is actually fine since it does not refer > >>> explicitely to the IPPM metrics registry. > >> > >> I think it would help if it said "Both measurement and non-measurement Tasks may have registry entries …." > >> > > > > You want me to repeat this sentence > > > > [...] Both measurement and non-measurement > > Tasks have registry entries to enable the MA to uniquely identify the > > Task it should execute and retrieve the schema for any parameters > > that may be passed to the Task. > > > > that is already in section 3.9 in the description of ma-task-functions > > (section 3.9.1)? > > No, sorry, I was just suggesting that you add the word “may." Ah, I see - I have added 'may'. > >>> What about this (right below Figure 1): > >>> > >>> The primary function of an MA is to execute Schedules. A Schedule, > >>> which is triggered by an Event, executes a number of Actions. An > >>> Action refers to a Configured Task and it may feed results to a > >>> Destination Schedule. Both, Actions and Configured Tasks can provide > >>> parameters, represented as Action Options and Task Options. > >> > >> Some minor tweaks: > >> > >> The primary function of an MA is to execute Schedules. A Schedule, > >> which is triggered by an Event, executes a number of Actions. An > >> Action is a Configured Task and it may feed results to a > >> Destination Schedule. Both Actions and Configured Tasks can provide > >> parameters, represented as Action Options and Task Options. > > > > Well, an Action refers to a Configured Task, I do not think it is > > correct to say an Action is a Configured Task. > > Then why does the text in later sections say "An Action is a Task with additional specific parameters”? That is where I am confused. I see. I replaced "Action is a Task" with "Action extends a Configured Task". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 31 06:15:56 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4B9129491 for ; Tue, 31 Jan 2017 06:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Fn8b9S9x; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Uw2hqWEU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7HSxDWyJ-1R for ; Tue, 31 Jan 2017 06:15:53 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C3B129488 for ; Tue, 31 Jan 2017 06:15:53 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2791722F8F; Tue, 31 Jan 2017 09:15:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 31 Jan 2017 09:15:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=VWFS596yIGVLs8U +8HmiQv/CAoE=; b=Fn8b9S9xVF5MTd4cUtlULm4jOCsWMd0xgCdwUAPp5bPrOyx DjHaa0oXBlhdjRGjnHnY8OnxymAF0FqbtQld5SpkO4hBTvtoWxFHmPqQWS7FsV26 Onk7KQ8qOguRzBDCIA/t3/Cutfr/RNZghOg4Aih/5ori1Xw5CzEfm43WfHZ0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=VWFS596yIGVLs8U+8HmiQv/CAoE=; b=Uw2hqWEU7WvxlFZWMiNP k4DU+G7iT3Z03MOZcsjYi9RnMWO9eneDCSv9Hw4HUJ7afwaG/LnWOKud+xhyButg ZdfgimY0qTDfhV5D1/Vi9Y5pDhbaTkZcaq2+uFMswlusIYi0vx2AhBZ8FhQr8OPQ 4ihXg86LJYIwn4keso8rnLY= X-ME-Sender: X-Sasl-enc: ByXkeitH78obAkCQunkQY82gAaULRzCl1Uj1rkcjRpJJ 1485872152 Received: from dhcp-10-150-9-142.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id DC2627E51C; Tue, 31 Jan 2017 09:15:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20170131094427.GA59387@elstar.local> Date: Tue, 31 Jan 2017 09:15:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 14:15:54 -0000 > On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder = wrote: >>=20 >=20 > The status reports go to the LMAP controller, so I do not really see > why there is a specific risk since the controller has access to the > device ID anyway. I still am missing what is the rationale for sending the device ID in = the status reports. I thought the agent ID was meant to uniquely = identify the MA. Alissa= From nobody Tue Jan 31 11:48:05 2017 Return-Path: X-Original-To: lmap@ietfa.amsl.com Delivered-To: lmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78F1293F9 for ; Tue, 31 Jan 2017 11:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxg5euTLITV2 for ; Tue, 31 Jan 2017 11:47:58 -0800 (PST) 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 DF5AA129586 for ; Tue, 31 Jan 2017 11:47:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 57D0D6D1; Tue, 31 Jan 2017 20:47:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9l12IJvAskJ5; Tue, 31 Jan 2017 20:47:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 Jan 2017 20:47:56 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA4C1200AD; Tue, 31 Jan 2017 20:47:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h4yj8p-1xyOk; Tue, 31 Jan 2017 20:47:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9796200AC; Tue, 31 Jan 2017 20:47:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 90A553E60D99; Tue, 31 Jan 2017 20:47:58 +0100 (CET) Date: Tue, 31 Jan 2017 20:47:57 +0100 From: Juergen Schoenwaelder To: Alissa Cooper Message-ID: <20170131194757.GA78531@elstar.local> Mail-Followup-To: Alissa Cooper , lmap@ietf.org References: <2CB94EA6-A5F9-4770-9E76-0C7E8676E9CF@cooperw.in> <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: lmap@ietf.org Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16 X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:48:00 -0000 On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote: > > > On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder wrote: > >> > > > > The status reports go to the LMAP controller, so I do not really see > > why there is a specific risk since the controller has access to the > > device ID anyway. > > I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA. > So here we go. I propose the following change: - The ma-status-agent-id becomes optional. - The ma-status-device-id becomes mandatory again. Rationale: If a device does not yet have an MA-ID, then the device-id must be accessible such that the controller can configure an MA-ID. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103