Subject: [lmap] remove ma-task form ma-instruction-obj

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Feb 2016 13:30:22 +0100

Hi,

while implementing things, I figured out that my daemon 'lmapd' needs,
in addition to instructions received from the controller, some basic
configuration information. In particular, configuration is needed
about the programs that are considered measurement tasks and 'safe' to
execute. (It does not make sense to allow a controller to execute
/bin/sh as a measurement task for obvious reasons). This configuration
information should not generally be writable.

Looking at the current information model, it seems this can be very
easily be achieved by removing ma-task from ma-instruction-obj into
the ma-config-obj. As a consequence of this change, the ma-task-obj is
not something that is exposed to be messed around with by a
controller. The controller is essentially restricted to 'play' with
schedules and suppressions (and we likely should add events to the
ma-instruction-obj). Note that with this cange, we would not really
need the recently added ma-capability-task-obj anymore since a
controller can read the (for the controller read-only) configured
tasks and then create schedules with actions referring to the
configured tasks.

In terms of implementation, what this boils down to is having a setup
where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd
itself including the configuration of the tasks that the lmapd allows
to be use. Instructions (locally generated or received from remote
controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon
startup, the lmapd would read and merge all these conf files to
produce the configuration that is executed. (There is likely a bit
more work to support multiple controllers with proper isolation but
that is outside the scope of LMAP for now I think.)

For the YANG data model, my preferred solution would be to tag the
leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC
6536) to document that this part of the configuration model usually is
not writable for controllers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Thu, 18 Feb 2016 20:40:11 +0000

Juergen,

An instruction gets sent down by the controller as part of a testing cycle; a config object (which includes is general configuration or preconfiguration) - I think you are blurring the lines - Note that there are control tasks in the config so these are the "safe config" tasks. The tasks in the instruction are testing tasks so they should be "safe" for testing. I don't think we should say or enforce anything more than that.

That being said in the BBF TR-069 implementation an MA has tasks some of which are referenced by the current instruction - these are known as test tasks by their reference to the instruction.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, February 18, 2016 12:30 PM
To: [email-masked]
Subject: [lmap] remove ma-task form ma-instruction-obj

Hi,

while implementing things, I figured out that my daemon 'lmapd' needs, in addition to instructions received from the controller, some basic configuration information. In particular, configuration is needed about the programs that are considered measurement tasks and 'safe' to execute. (It does not make sense to allow a controller to execute /bin/sh as a measurement task for obvious reasons). This configuration information should not generally be writable.

Looking at the current information model, it seems this can be very easily be achieved by removing ma-task from ma-instruction-obj into the ma-config-obj. As a consequence of this change, the ma-task-obj is not something that is exposed to be messed around with by a controller. The controller is essentially restricted to 'play' with schedules and suppressions (and we likely should add events to the ma-instruction-obj). Note that with this cange, we would not really need the recently added ma-capability-task-obj anymore since a controller can read the (for the controller read-only) configured tasks and then create schedules with actions referring to the configured tasks.

In terms of implementation, what this boils down to is having a setup where you have in /etc/lmapd/lmapd.conf the configuration of the lmapd itself including the configuration of the tasks that the lmapd allows to be use. Instructions (locally generated or received from remote
controllers) would go into /var/spool/lmapd/instructions/*.conf. Upon startup, the lmapd would read and merge all these conf files to produce the configuration that is executed. (There is likely a bit more work to support multiple controllers with proper isolation but that is outside the scope of LMAP for now I think.)

For the YANG data model, my preferred solution would be to tag the leafs in the /lmap/tasks/ subtree with nacm:default-deny-write (RFC
6536) to document that this part of the configuration model usually is not writable for controllers.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2016 13:09:18 +0100

> An instruction gets sent down by the controller as part of a testing cycle; a config object (which includes is general configuration or preconfiguration) - I think you are blurring the lines - Note…

Why does it make sense for a controller to send a task as part of an
instruction to the measurement agent? How does a measurement agent
decide whether such a task should be accepted or rejected?

> That being said in the BBF TR-069 implementation an MA has tasks some of which are referenced by the current instruction - these are known as test tasks by their reference to the instruction.

Referencing tasks is just fine. The question is whether a controller
should be allowed to send tasks down to the measurement agent.

/js

---

From: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Mon, 22 Feb 2016 17:20:24 +0000

Juergen,

If a task is sent down as part of the configuration object; its meant for maintaining its ecosystem; if it sent as part of the instruction its meant for testing. The MA should indeed know what tasks it allows for what purposes.

I didn't understand your comment - unless it is preconfigured a controller always sends down the task to the measurement agent...

BR,
Tim 

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, February 22, 2016 6:09 AM
To: Carey, Timothy (Nokia - US)
Cc: [email-masked]
Subject: Re: [lmap] remove ma-task form ma-instruction-obj

> An instruction gets sent down by the controller as part of a testing cycle; a config object (which includes is general configuration or preconfiguration) - I think you are blurring the lines - Note…

Why does it make sense for a controller to send a task as part of an instruction to the measurement agent? How does a measurement agent decide whether such a task should be accepted or rejected?

> That being said in the BBF TR-069 implementation an MA has tasks some of which are referenced by the current instruction - these are known as test tasks by their reference to the instruction.

Referencing tasks is just fine. The question is whether a controller should be allowed to send tasks down to the measurement agent.

/js
 
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]