Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

["Carey, Timothy (Timothy)" <[e-mail]>]

Juergen,

If you do not want to disable the scheduled tasks - I would actually say the Parent tasks not the schedules are disabled. The reason is because we are talking about wanted to disable Tasks that are not related to the communication between the MA and Controller or proper functioning of the MA.  The MA knows this as part of their TaskCapability reporting (which somehow got deleted in draft 05).

As to the reporting of the status I would do the following:
Add an OperationalStatus attribute with the following values to the action object (which was scheduled task): enabled, disabled-schedule, disabled-task, disabled-other.



I would also add an OperationalStatus to:
1) Schedule object with the following values: enabled, disabled-suppressed, disabled-other.
2) Task object (I guess it could go in Task Status) with the following values: enabled, disabled-suppressed, disabled-ma, disabled-other.
3) Measurement Agent object with the following values: enabled, degraded-controller-communication, degraded-other, disabled.

We would always include a disabled-other to allow other conditions. For example in TR-069 we have the capability to administratively enable/disable the multi-instance objects by conventions - so if for some reason these were administratively disabled - we would set the OperationalStatus to disabled-other or just disabled for the MA.

These status' would provide a clear operational status of the elements that can be disabled or degraded based on what is currently documented in the framework and information model. I would suspect as we implement protocols there might be other values we want to support - e.g., problems with the collector-MA communication...

BR,
Tim
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: Tuesday, May 12, 2015 9:20 AM
To: Carey, Timothy (Timothy)
Cc: [e-mail]
Subject: Re: [lmap] draft-ietf-lmap-information-model-05: Controller timeout

On Tue, May 12, 2015 at 01:04:49PM +0000, Carey, Timothy (Timothy) wrote:

> So does that now mean we need to have a operational status now for a 
> scheduled task? I can see it now as attribute with values like:
> enabled, disabled, suppressed and errored or possibly a conditions 
> object?

I think there two questions here:

a) If I loose connectivity, do I disable all schedules (and thus
   implicitely all actions) or do I disable scheduled tasks? My idea
   was to simply disable all schedules (and as such the schedules have
   their state changed to disabled).

   The suppression mechanism can suppress both a list of tasks and a
   list of schedules and it is configurable what is being suppressed.

   One option is that loss of connectivity simply causes suppression
   to be activated. Another option is that loss of connectivity
   supresses all tasks that are not essential for communication with a
   controller and house keeping. Another option is that loss of
   connectivity suppresses all schedules. We need to select one.

b) Do we expose the internal state that is maintained? Right now, we
   do not expose any operational state for schedules. But we do expose
   operational state for tasks. If loss of connectivity means we
   disable all tasks that are not essential for communication with a
   controller and house keeping, than exposing that information would
   be a rather minor change to the information and data model.

   A task state would then be enabled (default), suppressed or
   disabled. Error information is already covered in the last-failed
   attributes of a task. (And this is useful in situations where tasks
   fail occasionally so you can get information about the last failure
   even though the task is working fine right now).

/js

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