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 11:50:34AM +0200, Fredrik Kers wrote:
> Hi!
> I'm looking at aligning a project with the LMAP data model (
> https://tools.ietf.org/html/draft-ietf-lmap-information-model-18) and YANG
> model (https://tools.ietf.org/html/draft-ietf-lmap-yang-12) and have some
> questions and comments.

Note that the two documents have just been moved to the RFC editor
queue (after ~3 years of development within the WG). While comments
and questions are welcome, there likely won't be any technical changes
soon.
 
> 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.

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

> 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.
 
> And now some comments on the YANG model.
> 
> 4)
> In the YANG model, a task can be listed in three places;
> /lmap/capabilities/tasks/task, /lmap/tasks/task and
> /lmap/schedules/schedule/action/task. Let's see if I understand this
> correctly...
> 
> * /lmap/capabilities/tasks/task lists the available tasks that the MA can
> execute, which is not configurable from a controller but is configured
> locally at the MA, for example in a config file or even at compile time.
> * /lmap/tasks/task is the tasks that has been configured with some default
> options and are available to be executed.
> * /lmap/schedules/schedule/action/task pints at what task to start when an
> action is fired, and provides additional options to it.

Correct.
 
> To me it's not clear why the middle step (/lmap/tasks/task) is required
> since all the properties at that level (options and tags) can also be
> configured in the action, except the functions list which seems weird to be
> able to configure anyways (see next comment).

The 'middle step' is an optimization for situations when you have many
actions that want to share common task parameters.

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

> 6)
> To keep the structure of the YANG model consistent all lists should be
> wrapped in a container, e.g. move /lmap/schedules/schedule/action to
> /lmap/schedules/schedule/actions/action. Other lists that would be affected
> are "function", "option", "result", "conflict", "table" and "row". Is there
> a reason for the different structure of some lists?

YANG generally does not have nodes representing lists and some people
believe such additional containers just add additional noise to the
data encodings with little value.

The reason why we have the top-level containers is because people
found it useful to have some top-level structure (similar to the way
we have structured the information model into several aspects); so
these top-levels provide structure, they do not represent lists. For
example, /lmap/agent is just a container for scalars and
/lmap/capabilities is a container with scalars and a list.

/js

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