Subject: Re: [lmap] Question on information model - Suppression

From: [email-masked]
Date: Tue, 20 May 2014 19:26:55 +0300

It is very clear now Trevor.
Can't we imagine a scenario where the controller would  tell the MA to stop communicating with controller for a given period of time (maintenance or other reason...)?
  
marc.
-original message-
Subject: RE: [lmap] Question on information model - Suppression
From: <[email-masked]>
Date: 20/05/2014 18:53

The change that was agreed in London was that everything would be treated as a Task - meaning also that everything is run from a Schedule. The consequences of this is that we have a Control Schedule that executes the Control Tasks (that implement the Control Protocol). This is set in pre-configuration and can be updated in configuration.

We then have separate Instruction Schedules containing all other Tasks (e.g. measurement and reporting tasks). These are set as part of the Instruction.

The separation of these two sets of information (necessary since we need to communicate initially with a Controller before receiving Instruction) means we can exploit this in the effect of Suppression. This is what I was suggesting - anything in the 'control' information would not be suppressed. i.e. you can't suppress the MA talking with the Controller.

Sorry some of this is not very clear as it is agreed but unpublished work (forthcoming in revision 01).

Trevor Burbridge

>-----Original Message-----
>From: Charles Cook [mailto:[email-masked]]
>Sent: 20 May 2014 15:58
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: [lmap] Question on information model - Suppression
>
>Trevor,
>
>I'm not sure what the second dash item means - particularly the first
>half of the item regarding the controller communication schedule.
>Perhaps you can elaborate.
>
>Charles
>
>On 5/20/2014 2:14 AM, [email-masked] wrote:
>> This is where I was until we have everything as a task. Measurement tasks,
>reporting tasks, alarm collection tasks, Instruction fetching tasks). Without some
>sort of tweak a single "suppress" message could put the MA out of
>communication. A single suppress message without an endtime would put the MA
>out of communication permanently.
>>
>> The controller communication tasks at least need some sort of protection.
>>
>> Let me try an alternative that I think is close to Marc and Juergen:
>>
>> - as Marc suggests below (i.e. all tasks can be suppressed without distinction)
>> - BUT the tasks run in the controller communication schedule are exempt from
>suppression. i.e. suppression only affects the Instruction schedules.
>>
>> Trevor.
>>
>> Trevor Burbridge
>>
>>> -----Original Message-----
>>> From: marc.ibrahim [mailto:[email-masked]]
>>> Sent: 19 May 2014 20:11
>>> To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R
>>> Cc: [email-masked]; [email-masked]; [email-masked]
>>> Subject: Re: [lmap] Question on information model - Suppression
>>>
>>> I join Trevor in considering that no distinction should be made between active
>and
>>> passive tasks.
>>>
>>> For tasks suppression (Tasks array in suppression object), the controller is free
>to
>>> specify any kind of tasks it wishes to suppress. If it wants to suppress only
>active
>>> measurements, then it just lists them. I don't see that "Trevor flag" is useful
>here
>>> since the flag and the Tasks array are both under the Controller control.
>>>
>>> For schedule suppression (Schedules array), the flag would mean the
>following:
>>> being able to suppress a schedule S while keeping a "non suppressible" subset
>of
>>> tasks running according to S. In my opinion, it will complicate things as JS
>stated,
>>> especially that previous decisions privileged simplicity.
>>> I see that if the controller wants to define a subset of "non suppressible tasks,
>it
>>> can simply create a dedicated schedule for these tasks and not mix them with
>>> other suppressible tasks.
>>>
>>> BR,
>>>
>>> Marc.
>>>
>>>
>>>
>>> On Mon, 19 May 2014 20:23:41 +0200, Juergen Schoenwaelder wrote
>>>> On Mon, May 19, 2014 at 01:28:47PM +0100, [email-masked]
>wrote:
>>>>> It is just meant to be an extension of suppression to encompass currently
>>> executing
>>> tasks as well as those scheduled to operate in future.
>>>>> It doesn't at the moment make a judgement on whether that should be
>>> active/passive/non-measurement tasks or whether the suppression should
>stop
>>> the task
>>> running or block network traffic. We still need to agree these points.
>>>>> My opinion would definitely favour stopping the task running rather than
>>> simply
>>> blocking network traffic. Seems simpler to implement and stops any possible
>>> interaction
>>> problems between tasks.
>>>>> On the long-standing discussion on whether only to suppress active tasks,
>>> personally
>>> I'd rather not make an active vs passive semantic distinction. However, in the
>task
>>> configuration I am leaning towards having an arbitrary "suppressible" flag
>which
>>> would
>>> serve the same purpose (but be more flexible). One reason I'm leaning in this
>>> direction
>>> is that now everything is a task - we don't necessarily want suppression to take
>>> down
>>> the tasks that report errors or status, report to the Collector or communicate
>>> with the
>>> Controller etc. If we did this though we'd also need to say whether this can be
>>> over-
>>> ridden by actually specifying the task name in the task list to be suppressed.
>>>> Would it not make more sense to state that tasks not involved in
>>>> measurements are always not suppressible? Adding more flags and
>>>> special cases all adds complexity. Does every implementation have to
>>>> support the 'suppressible' flag on all tasks? Or is that something an
>>>> implementation can hardwire (even to the extreme where nothing is
>>>> suppressible)? How do I learn whether a certain task can be
>>>> suppressable for a given implementation - by trial and error? It is
>>>> all these little details that increase complexity for something that
>>>> ought to be simple and used only in rare situations...
>>>>
>>>> /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/>
>>>>
>>>> _______________________________________________
>>>> lmap mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/lmap
>>>
>>> --
>>> Open WebMail Project (http://openwebmail.org)
>> _______________________________________________
>> lmap mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lmap
>
>--
>
>Charles Cook
>Principal Architect
>Network
>5325 Zuni Street; Suite 224
>Denver, CO  80221
>Tel:  303.992.8952  Fax:  925.281.0662
>[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 May 2014 21:15:45 +0200

On Tue, May 20, 2014 at 07:26:55PM +0300, [email-masked] wrote:

> Can't we imagine a scenario where the controller would tell the MA
> to stop communicating with controller for a given period of time
> (maintenance or other reason...)?

The question is not whether we can imagine something but whether
things are worth adding additional complexity. Do any of the real
world systems out there have such a feature and was it found
essential? If not, lets move on.

/js

---

From: "marc.ibrahim" <[email-masked]>
Date: Tue, 20 May 2014 23:39:36 +0300

I agree JS. 
In fact, I was not proposing to add anything. It was just a reply to what Trevor said 
about that "you can't suppress the MA talking with the Controller."
So, to clarify my point, I am just saying that there is no need to have additional flags 
and that the controller can ask suppression of any task it wants. And as you said, this 
distinction could be hardwired in the MA. 
 
BR,

Marc.

On Tue, 20 May 2014 21:15:45 +0200, Juergen Schoenwaelder wrote

---

From: "marc.ibrahim" <[email-masked]>
Date: Tue, 20 May 2014 23:39:36 +0300

I agree JS. 
 
BR,

Marc.

---

From: <[email-masked]>
Date: Wed, 21 May 2014 09:12:07 +0100

Maybe, but let's remember that the Controller is always free to change the Control Schedule in the Configuration information.

Changing the Schedule is always an option where there is not enough flexibility in the Suppression information.

Trevor.

Trevor Burbridge

>From: [email-masked] [mailto:[email-masked]]
>Sent: 20 May 2014 17:27
>To: Burbridge,T,Trevor,TUB8 R; [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Can't we imagine a scenario where the controller would  tell the MA to stop
>communicating with controller for a given period of time (maintenance or other
>reason...)?
>
>marc.
>-original message-
>The change that was agreed in London was that everything would be treated as a
>Task - meaning also that everything is run from a Schedule. The consequences of
>this is that we have a Control Schedule that executes the Control Tasks (that
>implement the Control Protocol). This is set in pre-configuration and can be
>updated in configuration.
>
>We then have separate Instruction Schedules containing all other Tasks (e.g.
>measurement and reporting tasks). These are set as part of the Instruction.
>
>The separation of these two sets of information (necessary since we need to
>communicate initially with a Controller before receiving Instruction) means we
>can exploit this in the effect of Suppression. This is what I was suggesting -
>anything in the 'control' information would not be suppressed. i.e. you can't
>suppress the MA talking with the Controller.
>
>>reporting tasks, alarm collection tasks, Instruction fetching tasks).
>>Without some sort of tweak a single "suppress" message could put the MA
>>out of communication. A single suppress message without an endtime
>>would put the MA out of communication permanently.
>>>
>>>> can simply create a dedicated schedule for these tasks and not mix
>>>> them with other suppressible tasks.
>>>>
>>>> BR,
>>>>
>>>> Marc.
>>>>
>>>>
>>>>
>>>> blocking network traffic. Seems simpler to implement and stops any
>>>> possible interaction problems between tasks.
>>>> serve the same purpose (but be more flexible). One reason I'm
>>>> leaning in this direction is that now everything is a task - we
>>>> don't necessarily want suppression to take down the tasks that
>>>> report errors or status, report to the Collector or communicate with
>>>> the Controller etc. If we did this though we'd also need to say
>>>> whether this can be
>>>> over-
>>>>> special cases all adds complexity. Does every implementation have
>>>>> to support the 'suppressible' flag on all tasks? Or is that
>>>>> something an implementation can hardwire (even to the extreme where
>>>>> nothing is suppressible)? How do I learn whether a certain task can
>>>>> be suppressable for a given implementation - by trial and error? It
>>>>> is all these little details that increase complexity for something
>>>>> that ought to be simple and used only in rare situations...
>>>>>
>>>>> /js
>>>>>
>>>>> --

---

From: KEN KO <[email-masked]>
Date: Wed, 21 May 2014 11:53:54 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 21, 2014 4:12 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; KEN KO; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Trevor.

Trevor Burbridge

>Cc: [email-masked]; 
>Can't we imagine a scenario where the controller would  tell the MA to 
>stop communicating with controller for a given period of time 
>The change that was agreed in London was that everything would be 
>treated as a Task - meaning also that everything is run from a 
>Schedule. The consequences of this is that we have a Control Schedule 
>that executes the Control Tasks (that implement the Control Protocol). 
>This is set in pre-configuration and can be updated in configuration.
>
>The separation of these two sets of information (necessary since we 
>need to communicate initially with a Controller before receiving 
>Instruction) means we can exploit this in the effect of Suppression. 
>This is what I was suggesting - anything in the 'control' information 
>would not be suppressed. i.e. you can't suppress the MA talking with the Controller.
>
>>Without some sort of tweak a single "suppress" message could put the 
>>MA out of communication. A single suppress message without an endtime 
>>>> report errors or status, report to the Collector or communicate 
>>>> with the Controller etc. If we did this though we'd also need to 
>>>> say whether this can be
>>>> over-
>>>>> something an implementation can hardwire (even to the extreme 
>>>>> where nothing is suppressible)? How do I learn whether a certain 
>>>>> task can be suppressable for a given implementation - by trial and 
>>>>> error? It is all these little details that increase complexity for 
>>>>> something that ought to be simple and used only in rare situations...
>>>>>
>>>>> /js
>>>>>
>>>>> --
>>Tel:  303.992.8952  Fax:  925.281.0662 [email-masked]
>