Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12

Fredrik Kers <fredrik.kers@netrounds.com> Thu, 04 May 2017 08:32 UTC

Return-Path: <fredrik.kers@netrounds.com>
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 53F2D128796 for <lmap@ietfa.amsl.com>; Thu, 4 May 2017 01:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=netrounds-com.20150623.gappssmtp.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 AIFHT_XU0XHa for <lmap@ietfa.amsl.com>; Thu, 4 May 2017 01:32:42 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 E3406126CD8 for <lmap@ietf.org>; Thu, 4 May 2017 01:32:41 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id u65so10996000wmu.1 for <lmap@ietf.org>; Thu, 04 May 2017 01:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netrounds-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3W8FV2erleqpKCPmqkvHXQrIe3+xSzRymtFJltEgzqs=; b=UMHZ4n4ZKm9bCPwg69Ponk6ieKdF8D8X4Hl4sBJ548hDEXLH6nEjFmSdYKbzWYOZq1 sUlZXPsVO6P7Mu7M8QeEd2SiGyrZSBjTbv/vXLWhhN1ZjJsxb7vWAIOGZxDGyUw5JuTl XH7TFdeW2F4hgK6hkaPiOpp9gMLni1hvg9qPuBjrqJL8h26DSFU5aglerAlxTSWrAqjw mDQD37i3tZVlsL7ynhcEKrXw/G/Bttw/aKYPbQ/KLuXIWYBxdgO095lbyI6fNPrbSOfh Kvk1XhXW+Qssm2BQXk4b65bxQW0S2D8+osDlKpT/Eu8BbJ9MdwXYHCtenZ7SMajd/otR umWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3W8FV2erleqpKCPmqkvHXQrIe3+xSzRymtFJltEgzqs=; b=FVBxIBLUBcGbWZ/x46DWIpjlH3VSEhW+MEgyrnpyyYL+FnNfikzCgX0Nd3x3iL4qFI fWjVs2BNjWKFXQG9HmSPxAe1HCwZWsDahh34mvyQk5JPFYrkQqpL8RvNfcvSsVyJF2SZ Be1pqXMDOn5JXG2Cn1z7aPR0PCh00elvslWBRxy2Klw7anUAHlF6HJtADJFIALzVLJdF nvRMMimpuqWhTWsPCuiFl7axp4aVuJ3gUKj9lsZ8s3wjQGEqx0W85bq2uaKru22vIcI9 79cXf1agpJLNVrgWmgZ8ecYzaVzQV76d0kLI59vqRSwKjp/j6NepjVh5A71H15eUdoRs ryYQ==
X-Gm-Message-State: AN3rC/6Na2+bURecg53HOpnekw8Se3Ln8sGfUuxXerhMwN85YRWXjBgX s2NAxKOq8PaWhifVPIiKKKqGU/F0Ow==
X-Received: by 10.28.26.82 with SMTP id a79mr881517wma.119.1493886760028; Thu, 04 May 2017 01:32:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.16 with HTTP; Thu, 4 May 2017 01:32:39 -0700 (PDT)
In-Reply-To: <20170503144732.GA7170@elstar.local>
References: <CAKkp-KQCaV1F0SZDW93Ljw1CKVb8ZbqE8TKo=Ytkn58WOmK4tw@mail.gmail.com> <20170503102406.GC6642@elstar.local> <CAKkp-KROXUdN6QkczeGUodfSXDOd=CuyoiJm3Lc_CXOn3qgUMw@mail.gmail.com> <20170503144732.GA7170@elstar.local>
From: Fredrik Kers <fredrik.kers@netrounds.com>
Date: Thu, 4 May 2017 10:32:39 +0200
Message-ID: <CAKkp-KTsd_myVGzbrqs0UZVmKuBpX=J9PDNKWggs7610rXMz1A@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Fredrik Kers <fredrik.kers@netrounds.com>, lmap@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c05be0eaac1f5054eae9d40
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/apzys0Hjujws7NsXFEcTDdRXoN8>
Subject: Re: [lmap] Comments on draft-ietf-lmap-information-model-18 and draft-ietf-lmap-yang-12
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 08:32:44 -0000

On Wed, May 3, 2017 at 4:47 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de>; wrote:

> > > > First, some comments on the information model.
> > > >
> > > > 1)
> > > > Normally a task in computer terms means a process or a "unit of
> > > execution"
> > > > as it is described on Wikipedia (
> > > > https://en.wikipedia.org/wiki/Task_(computing)), while in LMAP it
> means
> > > a
> > > > program/executable, or a function in more abstract terms. I was
> confused
> > > > for quite some time until I understood that a task in LMAP actually
> > > meant.
> > > > I would suggest using a more common terminology, but I understand
> that it
> > > > might be a bit too late to change the name of such a central concept.
> > >
> > > I do not think task necessarily means executable in LMAP. The term
> > > task is used in order to stay away to some extend from implementation
> > > specifics.
> > >
> >
> > No, the information model does not mention how a Task should be
> > implemented, so it could be in any form. However, in the YANG model the
> > task is actually assumed to be an executable because of the "program"
> leaf
> > with the description "The (local) program to invoke in order to execute
> the
> > task."
> >
> > Anyway, my comment was not about whether a Task is realized as an
> > executable or not but that the term "task" in LMAP doesn't mean what you
> > would expect. But I understand that it's too late to change this.
>
> The question always is: Is there anything unclear impacting
> implementations and interoperability?
>

No, the RFC is clear.

> > > 5)
> > > > In /lmap/tasks/task you can configure a list of functions for a task,
> > > which
> > > > might or might not be the same functions listed in
> > > > /lmap/capabilities/tasks/task. The purpose of this functions lists
> is not
> > > > crystal clear to me, but it seems wrong that you can configure
> functions
> > > > that are not included in the capabilities.
> > >
> > > I assume an implementation would reject an attempt to configure a
> > > function that does not apply. What is your proposal? To have this
> > > spelled out more clearly in the YANG model? To have some sort of a
> > > must constraint to express this? (I would have to think about how to
> > > write this.)
> > >
> >
> > Of course you could solve it at the implementation level, but as a user
> of
> > an interface based on the YANG model I would wonder what to configure in
> > /lmap/tasks/task/function and why.
>
> The function ties into a registry. Until we have such a registry, this
> remains somewhat vague.
>
> > The /lmap/tasks/task/program leaf, which will have the same issue, has a
> > "nacm:default-deny-write" statement, that I assume is to prevent
> > configuration of it. Could something similar be done?
>
> The registry proponents would never configure a program; they would
> identify a function via a registy entry and the system would have to
> resolve how that maps to a program. Note that it is not mandatory to
> have a program configured.
>
> > An alternative is to remove the "program" and "function"
> > (registry-grouping) completely from the /lmap/tasks/task since they
> already
> > exist in the task in the capabilities which is referenced by name.
>
> An entry in the task list says which functions a task can provide. In
> the configured task, you might subset that.
>

So the purpose of the functions in /lmap/tasks/task is to configure what
functions (metrics) a task should produce? That makes sense. Would also
make sense if those functions could be configured at the action level, just
like like the options.

Another question. What is the purpose of
/schedules/schedule/action/parameters? Is it only to provide configuration
to the "task instance" that is not feasible to describe as an option?

Regards,
Fredrik

-- 
*Fredrik Kers* | CTO
*Netrounds* | Storgatan 7 | 972 38 LuleƄ | Sweden | www.netrounds.com