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

[Juergen Schoenwaelder <[e-mail]>]

On Wed, May 03, 2017 at 03:56:43PM +0200, Fredrik Kers wrote:
> 
> I just saw that. Congratulations! I hope I don't ruin your day with all
> these questions :)
>

People reading the documents are always welcome!
 
> > > 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?
 
> > > 2)
> > > The information model describes the concept of Measurement Task,
> > Reporting
> > > Task, Control Task, etc. (
> > > https://tools.ietf.org/html/draft-ietf-lmap-information-model-18#page-9
> > ),
> > > and that Control Tasks can be used to configure the Schedules, Tasks etc.
> > > on the MA. However it's not described what mechanism a Control Task uses
> > to
> > > configure the MA. The normal task input/output model only describes how
> > > data flows between instances of tasks and schedules, but does not give
> > any
> > > way to communicate with the MA itself. How is this supposed to work?
> >
> > It is (a) not required to implement things via control tasks and (b)
> > how control tasks do their work is and implementation detail.
> >
> 
> OK. Since the concept of Control Tasks is covered in the RFC, it would be
> good to clarify that the communication interface between the Control Task
> and the MA is outside of the scope of the RFC.

I would not disagree with such a statement but I do not find it
essential and well it is too late for the first version of the model.

> > 3)
> > > Related to this the Control Tasks, the information model in one place
> > > states that "in terms of the Information Model, all Tasks have the same
> > > structure", but in another place states that "Suppression has no effect
> > on
> > > either Controller Tasks or Controller Schedules".
> > >
> > > So the question is, is a Control Task (and Schedule) handled differently
> > by
> > > the MA compared to other types of Tasks (and Schedules)?
> >
> > In this particular aspect, they may be handled differently. If you,
> > for example, implement an LMAP agent running behind a NAT, then there
> > needs to be something that calls home to the controller. This
> > something might be implemented as a control task or it might be
> > implemented as part of the LMAP agent itself. If this would be
> > implemented as a control task, then attempts to suppress call home
> > would likely be rejected (since this would essentially mean the LMAP
> > agent becomes disconnected and hence useless). There may be additional
> > control tasks, e.g., a control task that clears buffered data in case
> > an LMAP agent is running low on memory. Again, an implementation may
> > not support suppression of such a house keeping control task.
> >
> 
> I understand the reason one might want to prevent suppression of certain
> Tasks, but stating that some Tasks should be treated differently without
> additional information on how to identify those Tasks leaves the reader
> wondering. If you think that it's up to the implementation to decide how to
> identify the task, I think than it should be mentioned.

A controller does not configure which tasks are control tasks. The MA
implementation knows them.

> > > 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>