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

[Fredrik Kers <[e-mail]>]

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.

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.

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?

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



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.

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

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.

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?

Regards,
Fredrik

-- 

*Fredrik Kers* | CTO | linkedin.com/company/netrounds
<https://www.linkedin.com/company/netrounds>

<[e-mail]>

*Netrounds* | Storgatan 9 | 972 38 Luleå | Sweden | www.netrounds.com