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

[Fredrik Kers <[e-mail]>]

On Wed, May 3, 2017 at 4:47 PM, Juergen Schoenwaelder <
[e-mail]> 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