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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Mar 2016 18:08:21 +0100

Tim,

why would a controller have to configure tasks? Why is it not
sufficient to send instructions consisting of schedules (and their
actions), suppressions and event definitions? What can be done by
sending tasks that can't be done by also done by sending actions?

/js

On Mon, Feb 22, 2016 at 05:20:24PM +0000, Carey, Timothy (Nokia - US) wrote:
> 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
> 
> On Thu, Feb 18, 2016 at 08:40:11PM +0000, Carey, Timothy (Nokia - US) wrote:
> > 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.
> >
> 
> 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
>  
> > -----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
> > 
> > -- 
> > 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/>
> > 
> > 
> 
> -- 
> 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/>

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