Subject: [lmap] Suppression in framework

From: <[email-masked]>
Date: Mon, 9 Jun 2014 17:42:33 +0100

So we have agreed to modify suppression so the default behaviour is that tasks have a Boolean flag which indicates whether or not a Suppress message will suppress them.
Question: what do we want the impact of the flag to be when we have the more complex, optional Suppress message? (it lists specific Tasks or Schedules for suppression.)
http://tools.ietf.org/html/draft-ietf-lmap-framework-05#page-15

Treating the Boolean flag as meaning "do-not-suppress this Measurement Task", my proposal is to basically keep the current text unaltered:

<< Optionally the Suppression information may
   include:

   o  a set of Measurement Tasks to suppress; the others are not
      suppressed.  For example, this could be useful if a particular
      Measurement Task is overloading a Measurement Peer.

   o  a set of Measurement Schedules to suppress; the others are not
      suppressed.  For example, suppose the measurement system has
      defined two Schedules, one with the most critical Measurement
      Tasks and the other with less critical ones that create a lot of
      Active Measurement Traffic, then it may only want to suppress the
      second.

   o  a start time, at which suppression begins

   o  an end time, at which suppression ends

   o  a demand that the MA ends its on-going Active Measurement Task(s)
      (and deletes the associated partial Measurement Result(s)).

In other words, if the Controller says "Suppress Task #213" then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn't start this Task. Similarly, if the Controller says "Suppress Schedule #49", then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn't start any new Tasks in this schedule.

I'll tweak the text to say this (as well as removing the refs to Active).
I'll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn't something that the MA decides about).

Thanks
phil

---

From: KEN KO <[email-masked]>
Date: Mon, 9 Jun 2014 16:49:11 +0000

I would think that information in the optional Suppress fields would override the default behavior flag. That is, if the do-not-suppress flag was set for a given task, yet a Suppression message specifically listed that same task (or schedule containing the Task), the task would then be suppressed and no error would be thrown.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 09, 2014 12:43 PM
To: [email-masked]
Subject: [lmap] Suppression in framework

Thanks
phil

---

From: <[email-masked]>
Date: Mon, 9 Jun 2014 17:56:22 +0100

Over-ride might make it a bit too easy to accidentally suppress a really crucial Task such as reporting to the collector or communication with the controller (since tasks are now general and not just measurement tasks).  Or deliberately by an attacker.

If the controller wants to suppress a task with the do-not-suppress flag set, then it would either re-does the task configuration or it updates the schedule

From: KEN KO [mailto:[email-masked]]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; [email-masked]
Subject: RE: Suppression in framework

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 09, 2014 12:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] Suppression in framework

Thanks
phil

---

From: KEN KO <[email-masked]>
Date: Mon, 9 Jun 2014 17:05:18 +0000

My interpretation of the existing text is that the option fields already override default behavior.

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I'm thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I'm still in favor of the optional fields overriding the default.

Your thoughts?

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; [email-masked]
Subject: RE: Suppression in framework

From: KEN KO [mailto:[email-masked]]
Sent: 09 June 2014 17:49
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: Suppression in framework

Thanks
phil

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Jun 2014 16:50:36 +0000

+1
Barbara

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Monday, June 09, 2014 12:49 PM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Thanks
phil

---

From: Charles Cook <[email-masked]>
Date: Mon, 09 Jun 2014 11:59:37 -0600

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the
Measurement Method.  If there is a possibility that the default can be
overwritten, then an optional field is added to the Measurement Method. 
If the Controller wants to override the default, it must assert the
optional override field when generating the Measurement Task.

I have not formed an opinion regarding MA communication with the Controller.

Charles

On 6/9/2014 11:05 AM, KEN KO wrote:
> Given the more general nature of Tasks as you point out, there may be
> specific tasks which should simply never be suppressed, either by
> default configuration or optional field. I'm thinking primarily about
> communication with the Controller. If we protect that, then
> suppression of anything else should be recoverable. And if that is
> true, I'm still in favor of the optional fields overriding the default.
>
>  
>
> Your thoughts?
>
>  
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Monday, June 09, 2014 12:56 PM
> *To:* KEN KO; [email-masked]
> *Subject:* RE: Suppression in framework
>
>  
>
> Over-ride might make it a bit too easy to accidentally suppress a
> really crucial Task such as reporting to the collector or
> communication with the controller (since tasks are now general and not
> just measurement tasks).  Or deliberately by an attacker.
>
>  
>
> If the controller wants to suppress a task with the do-not-suppress
> flag set, then it would either re-does the task configuration or it
> updates the schedule
>
>  
>
> *From:*KEN KO [mailto:[email-masked]]
> *Sent:* 09 June 2014 17:49
> *To:* Eardley,PL,Philip,TUB8 R; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Suppression in framework
>
>  
>
> I would think that information in the optional Suppress fields would
> override the default behavior flag. That is, if the do-not-suppress
> flag was set for a given task, yet a Suppression message specifically
> listed that same task (or schedule containing the Task), the task
> would then be suppressed and no error would be thrown.
>
>  
>
>  
>
> *From:*lmap [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* Monday, June 09, 2014 12:43 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [lmap] Suppression in framework
>
>  
>
> So we have agreed to modify suppression so the default behaviour is
> that tasks have a Boolean flag which indicates whether or not a
> Suppress message will suppress them.
>
> Question: what do we want the impact of the flag to be when we have
> the more complex, optional Suppress message? (it lists specific Tasks
> or Schedules for suppression.)  
>
> Treating the Boolean flag as meaning "do-not-suppress this Measurement
> Task", my proposal is to basically keep the current text unaltered:
>
>                                                                                     
>
>
> In other words, if the Controller says "Suppress Task #213" then the
> MA checks the do-not-suppress flag for Task #213 and either throws an
> error or doesn't start this Task. Similarly, if the Controller says
> "Suppress Schedule #49", then the MA checks the do-not-suppress flag
> for Tasks in this schedule and either throws an error or doesn't start
> any new Tasks in this schedule.
>
>  
>
> I'll also make clear that the Controller sets the do-not-suppress flag
> for a Task (it isn't something that the MA decides about).
>
>  
>
> Thanks
>
> phil
>
>
>
> _______________________________________________
> 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: KEN KO <[email-masked]>
Date: Mon, 9 Jun 2014 18:19:06 +0000

Charles,

Is there a reason to prevent the do-not-suppress flag from redefining the default suppression behavior suggested for a particular Measurement Method in a Registry, yet still allow it to be overridden by the optional suppression fields? Seems like that would be a needless limitation on the information model.

Ken

From: Charles Cook [mailto:[email-masked]]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Regarding suppression (not communication with the Controller):
My take is that the default suppression behavior can be coded into the Measurement Method.  If there is a possibility that the default can be overwritten, then an optional field is added to the Measurement Method.  If the Controller wants to override the default, it must assert the optional override field when generating the Measurement Task.

Charles

Your thoughts?

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, June 09, 2014 12:56 PM
To: KEN KO; [email-masked]<mailto:[email-masked]>
Subject: RE: Suppression in framework

Thanks
phil

lmap mailing list

[email-masked]<mailto:[email-masked]>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

[email-masked]<mailto:[email-masked]>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Jun 2014 18:23:45 +0000

+1
Barbara

From: lmap [mailto:[email-masked]] On Behalf Of KEN KO
Sent: Monday, June 09, 2014 1:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Your thoughts?

Thanks
phil

---

From: Charles Cook <[email-masked]>
Date: Mon, 09 Jun 2014 13:14:39 -0600

Ken,

I'm not sure I follow your question.  If there is a Measurement Method
that has been defined a priori such that the Suppression behavior
defined in the Measurement Method is not to be over-written, there
should be a flag set to indicate that the Suppression behavior cannot be
modified.  In other words, if the defined suppression behavior is
permitted to be changed, a flag in the Measurement Method would be set
to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain
control of what third-parties do relative to Suppression behavior on the
owner's Network.  It is possible that the owner of a Network could
create a registry of Measurement Methods that are allowable on their
Network by third parties that are using  a third-party Controller to
measure portions of the owner's Network.  The owner of the Network may
determine that within the set of Measurement Methods, there may be a
subset of Measurement Methods that the Network Owner always wants to be
suppressed when a suppression is sent, and does not want the third-party
Controller to ever override that behavior.

If the Network owner also owns the Controller, then I can't think of a
good reason to consider this method of dealing with Suppression.

Charles

On 6/9/2014 12:19 PM, KEN KO wrote:
>
> Charles,
>
>  
>
> Is there a reason to prevent the do-not-suppress flag from redefining
> the default suppression behavior suggested for a particular
> Measurement Method in a Registry, yet still allow it to be overridden
> by the optional suppression fields? Seems like that would be a
> needless limitation on the information model.
>
>  
>
> Ken
>
>  
>
> *From:*Charles Cook [mailto:[email-masked]]
> *Sent:* Monday, June 09, 2014 2:00 PM
> *To:* KEN KO; [email-masked]; [email-masked]
> *Subject:* Re: [lmap] Suppression in framework
>
>  
>
> overwritten, then an optional field is added to the Measurement
> Method.  If the Controller wants to override the default, it must
> assert the optional override field when generating the Measurement Task.
>
>     Given the more general nature of Tasks as you point out, there may
>     be specific tasks which should simply never be suppressed, either
>     by default configuration or optional field. I'm thinking primarily
>     about communication with the Controller. If we protect that, then
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     *To:* KEN KO; [email-masked] <mailto:[email-masked]>
>     communication with the controller (since tasks are now general and
>     not just measurement tasks).  Or deliberately by an attacker.
>
>      
>
>     If the controller wants to suppress a task with the
>     do-not-suppress flag set, then it would either re-does the task
>     configuration or it updates the schedule
>
>      
>
>     I would think that information in the optional Suppress fields
>     would override the default behavior flag. That is, if the
>     do-not-suppress flag was set for a given task, yet a Suppression
>     message specifically listed that same task (or schedule containing
>     the Task), the task would then be suppressed and no error would be
>     thrown.
>
>      
>
>      
>
>     So we have agreed to modify suppression so the default behaviour
>     is that tasks have a Boolean flag which indicates whether or not a
>     Question: what do we want the impact of the flag to be when we
>     have the more complex, optional Suppress message? (it lists
>     specific Tasks or Schedules for suppression.)  
>
>     Treating the Boolean flag as meaning "do-not-suppress this
>     Measurement Task", my proposal is to basically keep the current
>     text unaltered:
>
>                                                                                         
>
>
>     In other words, if the Controller says "Suppress Task #213" then
>     the MA checks the do-not-suppress flag for Task #213 and either
>     throws an error or doesn't start this Task. Similarly, if the
>     Controller says "Suppress Schedule #49", then the MA checks the
>     do-not-suppress flag for Tasks in this schedule and either throws
>     an error or doesn't start any new Tasks in this schedule.
>
>      
>
>     I'll also make clear that the Controller sets the do-not-suppress
>     flag for a Task (it isn't something that the MA decides about).
>
>      
>
>     Thanks
>
>     phil
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>

-- 

Charles Cook 
Principal Architect
Network

---

From: KEN KO <[email-masked]>
Date: Mon, 9 Jun 2014 19:35:38 +0000

OK, thanks. I read it wrong the first time. I can see some utility in that, but it does complicate the MA which would have to test suppression configuration in the Task against what is allowed by the Measurement Method.

From: Charles Cook [mailto:[email-masked]]
Sent: Monday, June 09, 2014 3:15 PM
To: KEN KO; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Ken,

I'm not sure I follow your question.  If there is a Measurement Method that has been defined a priori such that the Suppression behavior defined in the Measurement Method is not to be over-written, there should be a flag set to indicate that the Suppression behavior cannot be modified.  In other words, if the defined suppression behavior is permitted to be changed, a flag in the Measurement Method would be set to Suppression_Behavior_Modifiable : True.

A possible use case is one where a Network owner wants to maintain control of what third-parties do relative to Suppression behavior on the owner's Network.  It is possible that the owner of a Network could create a registry of Measurement Methods that are allowable on their Network by third parties that are using  a third-party Controller to measure portions of the owner's Network.  The owner of the Network may determine that within the set of Measurement Methods, there may be a subset of Measurement Methods that the Network Owner always wants to be suppressed when a suppression is sent, and does not want the third-party Controller to ever override that behavior.

If the Network owner also owns the Controller, then I can't think of a good reason to consider this method of dealing with Suppression.

Charles

Ken

From: Charles Cook [mailto:[email-masked]]
Sent: Monday, June 09, 2014 2:00 PM
To: KEN KO; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Suppression in framework

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: Charles Cook <[email-masked]>
Date: Mon, 09 Jun 2014 14:16:27 -0600

Good point.  Or the Controller can do the configuration manipulation in
the creation of the Measurement Task (my preference) so the MA does not
have to.  - keep the MA as simple as possible at the expense of the
Controller.

Charles

On 6/9/2014 1:35 PM, KEN KO wrote:
>
> OK, thanks. I read it wrong the first time. I can see some utility in
> that, but it does complicate the MA which would have to test
> suppression configuration in the Task against what is allowed by the
> Measurement Method.
>
>  
>
> *Sent:* Monday, June 09, 2014 3:15 PM
> should be a flag set to indicate that the Suppression behavior cannot
> be modified.  In other words, if the defined suppression behavior is
> control of what third-parties do relative to Suppression behavior on
> the owner's Network.  It is possible that the owner of a Network could
> subset of Measurement Methods that the Network Owner always wants to
> be suppressed when a suppression is sent, and does not want the
> third-party Controller to ever override that behavior.
>
>     Is there a reason to prevent the do-not-suppress flag from
>     redefining the default suppression behavior suggested for a
>     particular Measurement Method in a Registry, yet still allow it to
>     be overridden by the optional suppression fields? Seems like that
>     would be a needless limitation on the information model.
>
>      
>
>     Ken
>
>      
>
>     *To:* KEN KO; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     My take is that the default suppression behavior can be coded into
>     the Measurement Method.  If there is a possibility that the
>     default can be overwritten, then an optional field is added to the
>     Measurement Method.  If the Controller wants to override the
>     default, it must assert the optional override field when
>     generating the Measurement Task.
>
>         My interpretation of the existing text is that the option
>         fields already override default behavior.
>
>          
>
>         Given the more general nature of Tasks as you point out, there
>         may be specific tasks which should simply never be suppressed,
>         either by default configuration or optional field. I'm
>         thinking primarily about communication with the Controller. If
>         we protect that, then suppression of anything else should be
>         recoverable. And if that is true, I'm still in favor of the
>         optional fields overriding the default.
>
>          
>
>         Your thoughts?
>
>          
>
>         Over-ride might make it a bit too easy to accidentally
>         suppress a really crucial Task such as reporting to the
>         collector or communication with the controller (since tasks
>         are now general and not just measurement tasks).  Or
>         deliberately by an attacker.
>
>          
>
>         do-not-suppress flag set, then it would either re-does the
>         task configuration or it updates the schedule
>
>          
>
>         do-not-suppress flag was set for a given task, yet a
>         Suppression message specifically listed that same task (or
>         schedule containing the Task), the task would then be
>         suppressed and no error would be thrown.
>
>          
>
>          
>
>         So we have agreed to modify suppression so the default
>         behaviour is that tasks have a Boolean flag which indicates
>         whether or not a Suppress message will suppress them.
>
>         Measurement Task", my proposal is to basically keep the
>         current text unaltered:
>
>                                                                                             
>
>
>         In other words, if the Controller says "Suppress Task #213"
>         then the MA checks the do-not-suppress flag for Task #213 and
>         either throws an error or doesn't start this Task. Similarly,
>         if the Controller says "Suppress Schedule #49", then the MA
>         checks the do-not-suppress flag for Tasks in this schedule and
>         either throws an error or doesn't start any new Tasks in this
>         schedule.
>
>          
>
>         I'll also make clear that the Controller sets the
>         do-not-suppress flag for a Task (it isn't something that the
>         MA decides about).
>
>          
>
>         Thanks
>
>         phil
>
>
>
>
>

-- 

Charles Cook 
Principal Architect
Network

---

From: Charles Cook <[email-masked]>
Date: Mon, 09 Jun 2014 14:42:47 -0600

As soon as I hit send, that thought occurred to me as well, and whether
it would be out of scope. 

Your comment on the MA having to test the configuration against what is
allowed by the Measurement Method may be more trust worthy from the
perspective of the Network owner than the third-party Controller.  The
Network owner certainly would not be precluded from designing its MAs to
perform such a test against the Measurement Method.

I think I am convinced that maybe this is better handled by an agreement
between parties.

Charles

On 6/9/2014 2:27 PM, KEN KO wrote:
>
> But if a third party Controller can be trusted to do the right thing,
> then there seems to be little value in a flag in the Measurement
> Method that prohibits doing the wrong thing.
>
>  
>
> Perhaps if that is the case, this is better handled by an agreement
> between parties that would be out of scope for lmap?
>
>  
>
> *Sent:* Monday, June 09, 2014 4:16 PM
> Good point.  Or the Controller can do the configuration manipulation
> in the creation of the Measurement Task (my preference) so the MA does
> not have to.  - keep the MA as simple as possible at the expense of
> the Controller.
>
> Charles
>
>     OK, thanks. I read it wrong the first time. I can see some utility
>     in that, but it does complicate the MA which would have to test
>     suppression configuration in the Task against what is allowed by
>     the Measurement Method.
>
>      
>
>     I'm not sure I follow your question.  If there is a Measurement
>     Method that has been defined a priori such that the Suppression
>     behavior defined in the Measurement Method is not to be
>     over-written, there should be a flag set to indicate that the
>     Suppression behavior cannot be modified.  In other words, if the
>     defined suppression behavior is permitted to be changed, a flag in
>     the Measurement Method would be set to
>     Suppression_Behavior_Modifiable : True.
>
>     control of what third-parties do relative to Suppression behavior
>     on the owner's Network.  It is possible that the owner of a
>     Network could create a registry of Measurement Methods that are
>     allowable on their Network by third parties that are using  a
>     third-party Controller to measure portions of the owner's
>     Network.  The owner of the Network may determine that within the
>     set of Measurement Methods, there may be a subset of Measurement
>     Methods that the Network Owner always wants to be suppressed when
>     a suppression is sent, and does not want the third-party
>     If the Network owner also owns the Controller, then I can't think
>     of a good reason to consider this method of dealing with Suppression.
>
>     Charles
>
>         particular Measurement Method in a Registry, yet still allow
>         it to be overridden by the optional suppression fields? Seems
>         like that would be a needless limitation on the information model.
>
>          
>
>         Ken
>
>          
>
>         My take is that the default suppression behavior can be coded
>         into the Measurement Method.  If there is a possibility that
>         the default can be overwritten, then an optional field is
>         added to the Measurement Method.  If the Controller wants to
>         override the default, it must assert the optional override
>         field when generating the Measurement Task.
>
>             Given the more general nature of Tasks as you point out,
>             there may be specific tasks which should simply never be
>             suppressed, either by default configuration or optional
>             field. I'm thinking primarily about communication with the
>             Controller. If we protect that, then suppression of
>             anything else should be recoverable. And if that is true,
>             I'm still in favor of the optional fields overriding the
>             default.
>
>              
>
>             Your thoughts?
>
>              
>
>             *From:[email-masked]
>             <mailto:[email-masked]> [mailto:[email-masked]]
>             collector or communication with the controller (since
>             tasks are now general and not just measurement tasks).  Or
>             I would think that information in the optional Suppress
>             fields would override the default behavior flag. That is,
>             if the do-not-suppress flag was set for a given task, yet
>             a Suppression message specifically listed that same task
>             (or schedule containing the Task), the task would then be
>             behaviour is that tasks have a Boolean flag which
>             indicates whether or not a Suppress message will suppress
>             them.
>
>             Question: what do we want the impact of the flag to be
>             when we have the more complex, optional Suppress message?
>             (it lists specific Tasks or Schedules for suppression.)  
>
>             In other words, if the Controller says "Suppress Task
>             #213" then the MA checks the do-not-suppress flag for Task
>             #213 and either throws an error or doesn't start this
>             Task. Similarly, if the Controller says "Suppress Schedule
>             #49", then the MA checks the do-not-suppress flag for
>             Tasks in this schedule and either throws an error or
>             doesn't start any new Tasks in this schedule.
>
>              
>
>             do-not-suppress flag for a Task (it isn't something that
>             the MA decides about).
>
>              
>
>             Thanks
>
>             phil
>
>
>
>
>
>

-- 

Charles Cook 
Principal Architect
Network

---

From: KEN KO <[email-masked]>
Date: Mon, 9 Jun 2014 20:27:57 +0000

But if a third party Controller can be trusted to do the right thing, then there seems to be little value in a flag in the Measurement Method that prohibits doing the wrong thing.

Perhaps if that is the case, this is better handled by an agreement between parties that would be out of scope for lmap?

From: Charles Cook [mailto:[email-masked]]
Sent: Monday, June 09, 2014 4:16 PM
To: KEN KO; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Good point.  Or the Controller can do the configuration manipulation in the creation of the Measurement Task (my preference) so the MA does not have to.  - keep the MA as simple as possible at the expense of the Controller.

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 09:21:01 +0100

My take is that the do-not-suppress flag should not be defined in the Measurement Method. The controller should be able to set it. for some operators of measurement systems a particular method may be critical, for some it may be highly optional.

Allowing the optional msg to over-ride the do-not-suppress flag - I don't think this is very clean. There are some tasks (communication with controller) that would need to be marked as 'really do not suppress, even if the optional msg says so'. Perhaps also it would mean that the normal suppress and optional suppress msgs would have to be processed differently.

From: Charles Cook [mailto:[email-masked]]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; [email-masked]
Subject: Re: [lmap] Suppression in framework

As soon as I hit send, that thought occurred to me as well, and whether it would be out of scope.

Your comment on the MA having to test the configuration against what is allowed by the Measurement Method may be more trust worthy from the perspective of the Network owner than the third-party Controller.  The Network owner certainly would not be precluded from designing its MAs to perform such a test against the Measurement Method.

I think I am convinced that maybe this is better handled by an agreement between parties.

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 09:26:37 +0100

The last bit is important - when we just send a basic suppress message (i.e. default suppress everything) then this DOESN'T over-ride the flags. I wouldn't be in favour of reversing this when selected tasks/schedules are listed. I think this would create confusion.

Also I'm in favour of not over-riding to give a bit more accidental protection to critical tasks, such as communicating with the Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove the task from the schedules. So we always have the ability to switch off any task.

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 10 June 2014 09:21
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

From: Charles Cook [mailto:[email-masked]]
Sent: 09 June 2014 21:43
To: KEN KO; Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Suppression in framework

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: KEN KO <[email-masked]>
Date: Tue, 10 Jun 2014 12:53:48 +0000

It seems that we are expressing two different interpretations of this flag, and we need to converge on one.

Definition "A"
What I proposed is a flag that *defines* the default suppression behavior of a task, e.g. in response to a basic suppress message. In that context, Trevor's first sentence has no meaning because the flags themselves define the response to a basic suppress message - that is, there is nothing to override. The MA interprets the basic suppression message as "do what the flag says" for each Task. If the flag is cleared, the task is suppressed by default (using Phil's do-not-suppress polarity - I would reverse it, but that's a minor point). If the flag is set, the task is not suppressed by default.

Definition "B"
Trevor and Phil, I think (please correct me if this is wrong) you are interpreting these flags as identifying exceptions to predefined default suppression behavior. That is, if the flag is not set the suppression behavior conforms to a fixed definition, but if the flag is set the Task is not suppressed. This is a one-way flag - there is no way to use it to change the default behavior of a Task that is not normally suppressed. Is this understanding of your interpretation correct?

For what it is worth, I favor "A". I proposed it to resolve any ambiguity in the definition of Active vs. Passive as it applies to default suppression behavior while allowing each operator to define that behavior on their own terms. "B" doesn't achieve either of those goals.

Having said all that, I agree with you that communication with the Controller should never be suppressed. (I've seen it listed several times as an example of a critical task, but no other examples come to mind that aren't recoverable via a new Instruction from the Controller.) So let us define communication with a Controller as always being exempt from suppression. The MA is configured with the Controller's address so it is possible to mark any Task communicating with that address as "never suppress." This marking can be done at configuration time (internally by the MA, no Instruction field required) so addresses don't need to be compared at run time.

Ken

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 10, 2014 4:27 AM
To: [email-masked]; [email-masked]; KEN KO; [email-masked]
Subject: RE: [lmap] Suppression in framework

Trevor.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 June 2014 09:21
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Suppression in framework

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Jun 2014 13:06:17 +0000

I disagree.
This flag we are talking about could mean one of 2 things (providing the true and false of each):

1.       Do not ever suppress / suppress in absence of specific list

2.       Default suppress behavior (in the absence of a specific list)

I hear Phil and Trevor in favor of 1. I'm in favor of 2. 2 is definitely not confusing -- I see this sort of override behavior all the time. In fact, it's easier to code than the first, because once you have a specific list you don't have to compare it against the flag to see if it's allowed. Also, if certain tasks don't get suppressed (contrary to the specific list I just sent) there would need to be specific error messages and/or logs explaining why the MA ignored my specific instructions, and I would have to go look at these messages to figure out why my suppress message partially failed, craft a message to update the flags, and then re-suppress. Or, do I? If I do change the flag after having issued a suppress message, will the task be suppressed because of the prior suppress message that is in effect, or do I have to resend suppress? I don't know. Option 1 is creating confusion for me.

Since the same entity controls the flag as controls the suppress message, I don't see the need for this added level of protection (flag cannot be overridden). Don't shoot yourself in the foot. It's a bad idea. But it's not my job to keep someone from picking up a weapon and pointing it at their foot. I'm not a babysitter.

Personally, I would design the MA-Controller interface with code that would never allow it to be suppressed. I don't particularly think this needs to be mentioned in the info model or framework, because it's a pretty obvious design choice. But I also don't care if it does get mentioned. I just find that documents get incredibly long when all obvious design choices get written down.

Another possible design choice would be that the Controller system that lets the suppress message be created or issued by a human being compares the items in the specific list against the flags up front and warns the human being with an "Are you sure, because you'll be overriding these flags?" message. Or if no specific list is provided the system presents the human being with a "These are the tasks that will be suppressed; are you sure you want to do this?" message. There are plenty of ways to do this without making the flag an absolute that can easily be overwritten (but not overridden).
Barbara

IMO, the simple and not confusing behavior is 2.
Barbara

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 10, 2014 4:27 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Suppression in framework

Trevor.

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: KEN KO <[email-masked]>
Date: Tue, 10 Jun 2014 13:17:11 +0000

Sorry if this is a duplicate - I had to reset my membership in the lmap list.

Definition "A"

Definition "B"

Ken

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, June 10, 2014 4:27 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; KEN KO; [email-masked]<mailto:[email-masked]>
Subject: RE: [lmap] Suppression in framework

Trevor.

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 13:28:58 +0100

i don't think that's the difference.

Example:
tasks 1,2,3 have flag can-be-suppressed
tasks 4,5 have flag do-not-suppress

General "Suppress" msg: suppresses 1,2,3 (no disagreement)

"SUppress 2": suppresses 2 only (no disagreement)

"Suppress 4":
disagreement
Barbara: it suppresses 4
Trevor: it throws an error
XX: it suppresses 1,2,3,4 (dont think anyone has suggested this, but someone might argue for it)

Also,
"Unsuppress"
I think there's an implicit agreement that there is just a simple unsuppress msg (which unsupresses any task that is suppressed)
(ie no-one is suggesting also allowing an "Unsuppress 1" msg (that would unsuppress task 1 but leave other tasks suppressed)
(I think we should only have the simple "Unsuppress" msg)

________________________________
From: KEN KO [[email-masked]]
Sent: 10 June 2014 14:17
To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; [email-masked]; [email-masked]
Subject: RE: [lmap] Suppression in framework

Sorry if this is a duplicate – I had to reset my membership in the lmap list.

Definition “A”
What I proposed is a flag that *defines* the default suppression behavior of a task, e.g. in response to a basic suppress message. In that context, Trevor’s first sentence has no meaning because the flags themselves define the response to a basic suppress message – that is, there is nothing to override. The MA interprets the basic suppression message as “do what the flag says” for each Task. If the flag is cleared, the task is suppressed by default (using Phil’s do-not-suppress polarity – I would reverse it, but that’s a minor point). If the flag is set, the task is not suppressed by default.

Definition “B”
Trevor and Phil, I think (please correct me if this is wrong) you are interpreting these flags as identifying exceptions to predefined default suppression behavior. That is, if the flag is not set the suppression behavior conforms to a fixed definition, but if the flag is set the Task is not suppressed. This is a one-way flag – there is no way to use it to change the default behavior of a Task that is not normally suppressed. Is this understanding of your interpretation correct?

For what it is worth, I favor “A”. I proposed it to resolve any ambiguity in the definition of Active vs. Passive as it applies to default suppression behavior while allowing each operator to define that behavior on their own terms. “B” doesn’t achieve either of those goals.

Having said all that, I agree with you that communication with the Controller should never be suppressed. (I’ve seen it listed several times as an example of a critical task, but no other examples come to mind that aren’t recoverable via a new Instruction from the Controller.) So let us define communication with a Controller as always being exempt from suppression. The MA is configured with the Controller’s address so it is possible to mark any Task communicating with that address as “never suppress.” This marking can be done at configuration time (internally by the MA, no Instruction field required) so addresses don’t need to be compared at run time.

Ken

The last bit is important – when we just send a basic suppress message (i.e. default suppress everything) then this DOESN’T over-ride the flags. I wouldn’t be in favour of reversing this when selected tasks/schedules are listed. I think this would create confusion.

Also I’m in favour of not over-riding to give a bit more accidental protection to critical tasks, such as communicating with the Controller. Remember if we do want to over-ride any flags, the controller is free to either change those flags or remove the task from the schedules. So we always have the ability to switch off any task.

Trevor.

Allowing the optional msg to over-ride the do-not-suppress flag – I don’t think this is very clean. There are some tasks (communication with controller) that would need to be marked as ‘really do not suppress, even if the optional msg says so’. Perhaps also it would mean that the normal suppress and optional suppress msgs would have to be processed differently.

Charles

Charles

Ken,

Charles

Ken

Charles

Given the more general nature of Tasks as you point out, there may be specific tasks which should simply never be suppressed, either by default configuration or optional field. I’m thinking primarily about communication with the Controller. If we protect that, then suppression of anything else should be recoverable. And if that is true, I’m still in favor of the optional fields overriding the default.

Your thoughts?

Treating the Boolean flag as meaning “do-not-suppress this Measurement Task”, my proposal is to basically keep the current text unaltered:

In other words, if the Controller says “Suppress Task #213” then the MA checks the do-not-suppress flag for Task #213 and either throws an error or doesn’t start this Task. Similarly, if the Controller says “Suppress Schedule #49”, then the MA checks the do-not-suppress flag for Tasks in this schedule and either throws an error or doesn’t start any new Tasks in this schedule.

I’ll tweak the text to say this (as well as removing the refs to Active).
I’ll also make clear that the Controller sets the do-not-suppress flag for a Task (it isn’t something that the MA decides about).

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662[data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAKLSURBVHjadJPfS5NhFMe/21xvuhXRyJAZroiSrJnbRdT7vrAf5HBaK5RABmEEwQIvkpZ/QRcWXdSFw5soKaF0F7qZeLO13mGBDpQsf5CoxVKHOt0Pctp2uvEdrzG/V+c553w/54HnPDIiQiGpPMETABoB2AAYd9MRAMMAvGmX+RcAyAoBVJ7gZQDtABworH4AHWmX+bOMZdkjCoXiUzabvcAwzPSsob5p/VTNY9GcdpnxdmYZ9wJThSCtCr1e/4XjuNPd3d1KjUZzaGbI27ysqzGQoggAsLa1A7ehArrDxfDNr0oBlQB+wmKxbJFEL968SxoamsjkHaPU9l9piUo6A0RE1DG2QCWdASrpDAzJM5kMI8XecdjVxfEl+K9dxFgsgUvvR6HyBKHyBAEATyKLeGSsENuNcqk5kUjEGm7fzcYqr0ClVODl99+YXEvl6+c1amjVe+ahiGGYaUEQKnmeh91uL43rqheixjpdmzCL11er0PcjhrTLvMfUJsyKYUSeyWQ6enp6tgCgrKxsfbP8bB8AdE1G89cOReMAgOv+Cag8QXRNRkXAsDwcDr+am5tLCYKA3t7eo2dG+1vVK/MfpRPtA+MIReMYaKj+/xm9MiICx3EmpVL5wefzFavValis1u1vvHMkdfykCQC0kSGUTo+Ajmnx1dSC7IGD+UUCEYGIwLKsyWazrSeTSSIiMpnNf7Ttz5+ec96fr7/VnE0mk+QfHMzV3WjcKH/4rEr05QGFIA6HY4llWRLPRER+v3/HYrFMFQSIkNra2tVQKJSlfcSyLO0LECFWq3XF6XRGA4HAptTsdrsXeZ6fEHtl+31nAOA4rkUulz/I5XL63dQGgHEAN8Ph8AYA/BsAt4ube4GblQIAAAAASUVORK5CYII=]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>

---

From: KEN KO <[email-masked]>
Date: Wed, 11 Jun 2014 12:36:01 +0000

Inline ...

Example:

I agree with everything above.

"Suppress 4":
disagreement
Barbara: it suppresses 4

I agree with Barbara. (And I hope no one argues for XX!)

Also,
"Unsuppress"

Agreed.

To: Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Definition "A"

Definition "B"

Ken

Trevor.

Charles

Charles

Ken,

Charles

Ken

Charles

Your thoughts?

Thanks
phil

lmap mailing list

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>  Fax:  925.281.0662[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>  Fax:  925.281.0662[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>  Fax:  925.281.0662[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>

--

Charles Cook

Principal Architect

Network

Denver, CO  80221

Tel:  303.992.8952[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>  Fax:  925.281.0662[http://portal.mxlogic.com/images/transparent.gif]<https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ>

---

From: Michael Faath <[email-masked]>
Date: Wed, 11 Jun 2014 15:38:14 +0200

I think this describes the different views, inline:

> someone might argue for it)

I agree with Trevor, if a task has the do-not-suppress flag set it
should never be suppressed. The only way for suppressing this task
should be by sending a new schedule or update the task with the flag not
set.

>  
> Also,
> "Unsuppress"
> I think there's an implicit agreement that there is just a simple
> unsuppress msg (which unsupresses any task that is suppressed)
> (ie no-one is suggesting also allowing an "Unsuppress 1" msg (that would
> unsuppress task 1 but leave other tasks suppressed)

+1

Michael

>  
> ------------------------------------------------------------------------
> *From:* KEN KO [[email-masked]]
> *Sent:* 10 June 2014 14:17
> *To:* Burbridge,T,Trevor,TUB8 R; Eardley,PL,Philip,TUB8 R;
> [email-masked]; [email-masked]
> *Subject:* RE: [lmap] Suppression in framework
> 
> What I proposed is a flag that **defines** the default suppression
> behavior of a task, e.g. in response to a basic suppress message. In
> that context, Trevor’s first sentence has no meaning because the flags
> themselves define the response to a basic suppress message – that is,
> there is nothing to override. The MA interprets the basic suppression
> message as “do what the flag says” for each Task. If the flag is
> cleared, the task is suppressed by default (using Phil’s do-not-suppress
> polarity – I would reverse it, but that’s a minor point). If the flag is
> set, the task is not suppressed by default.
> 
>  
> 
> Definition “B”
> 
> Trevor and Phil, I think (please correct me if this is wrong) you are
> interpreting these flags as identifying exceptions to predefined default
> suppression behavior. That is, if the flag is not set the suppression
> behavior conforms to a fixed definition, but if the flag is set the Task
> is not suppressed. This is a one-way flag – there is no way to use it to
> change the default behavior of a Task that is not normally suppressed.
> Is this understanding of your interpretation correct?
> 
>  
> 
> For what it is worth, I favor “A”. I proposed it to resolve any
> ambiguity in the definition of Active vs. Passive as it applies to
> default suppression behavior while allowing each operator to define that
> behavior on their own terms. “B” doesn’t achieve either of those goals.
> 
>  
> 
> Having said all that, I agree with you that communication with the
> Controller should never be suppressed. (I’ve seen it listed several
> times as an example of a critical task, but no other examples come to
> mind that aren’t recoverable via a new Instruction from the Controller.)
> So let us define communication with a Controller as always being exempt
> from suppression. The MA is configured with the Controller’s address so
> it is possible to mark any Task communicating with that address as
> “never suppress.” This marking can be done at configuration time
> (internally by the MA, no Instruction field required) so addresses don’t
> need to be compared at run time.
> 
>  
> 
> Ken
> 
>  
> 
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Tuesday, June 10, 2014 4:27 AM
> *To:* [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>;
> KEN KO; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [lmap] Suppression in framework
> 
>  
> 
> The last bit is important – when we just send a basic suppress message
> (i.e. default suppress everything) then this DOESN’T over-ride the
> flags. I wouldn’t be in favour of reversing this when selected
> tasks/schedules are listed. I think this would create confusion.
> 
>  
> 
> Also I’m in favour of not over-riding to give a bit more accidental
> protection to critical tasks, such as communicating with the Controller.
> Remember if we do want to over-ride any flags, the controller is free to
> either change those flags or remove the task from the schedules. So we
> always have the ability to switch off any task.
> 
>  
> 
> Trevor.
> 
>  
> 
>  
> 
> *Sent:* 10 June 2014 09:21
> *To:* [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> My take is that the do-not-suppress flag should not be defined in the
> Measurement Method. The controller should be able to set it. for some
> operators of measurement systems a particular method may be critical,
> for some it may be highly optional.
> 
>  
> 
> Allowing the optional msg to over-ride the do-not-suppress flag – I
> don’t think this is very clean. There are some tasks (communication with
> controller) that would need to be marked as ‘really do not suppress,
> even if the optional msg says so’. Perhaps also it would mean that the
> normal suppress and optional suppress msgs would have to be processed
> differently.
> 
>  
> 
>  
> 
>  
> 
> *Sent:* 09 June 2014 21:43
> *To:* KEN KO; Eardley,PL,Philip,TUB8 R; [email-masked] <mailto:[email-masked]>
>     But if a third party Controller can be trusted to do the right
>     thing, then there seems to be little value in a flag in the
>     Measurement Method that prohibits doing the wrong thing.
> 
>      
> 
>     *To:* KEN KO; [email-masked] <mailto:[email-masked]>;
>     in the creation of the Measurement Task (my preference) so the MA
>     does not have to.  - keep the MA as simple as possible at the
>     expense of the Controller.
> 
>     Charles
> 
>         OK, thanks. I read it wrong the first time. I can see some
>         utility in that, but it does complicate the MA which would have
>         to test suppression configuration in the Task against what is
>         allowed by the Measurement Method.
> 
>          
> 
>         defined suppression behavior is permitted to be changed, a flag
>         in the Measurement Method would be set to
>         A possible use case is one where a Network owner wants to
>         maintain control of what third-parties do relative to
>         Suppression behavior on the owner's Network.  It is possible
>         that the owner of a Network could create a registry of
>         Measurement Methods that are allowable on their Network by third
>         parties that are using  a third-party Controller to measure
>         portions of the owner's Network.  The owner of the Network may
>         determine that within the set of Measurement Methods, there may
>         be a subset of Measurement Methods that the Network Owner always
>         wants to be suppressed when a suppression is sent, and does not
>         want the third-party Controller to ever override that behavior.
> 
>         If the Network owner also owns the Controller, then I can't
>         think of a good reason to consider this method of dealing with
>         Suppression.
> 
>         Charles
> 
>             it to be overridden by the optional suppression fields?
>             Seems like that would be a needless limitation on the
>             information model.
> 
>              
> 
>             Ken
> 
>              
> 
>             My take is that the default suppression behavior can be
>             coded into the Measurement Method.  If there is a
>             possibility that the default can be overwritten, then an
>             optional field is added to the Measurement Method.  If the
>             Controller wants to override the default, it must assert the
>                 My interpretation of the existing text is that the
>                 option fields already override default behavior.
> 
>                  
> 
>                 field. I’m thinking primarily about communication with
>                 the Controller. If we protect that, then suppression of
>                 anything else should be recoverable. And if that is
>                 true, I’m still in favor of the optional fields
>                 overriding the default.
> 
>                  
> 
>                 Your thoughts?
> 
>                  
> 
>                 tasks are now general and not just measurement tasks).
>                  Or deliberately by an attacker.
> 
>                  
> 
>                 do-not-suppress flag set, then it would either re-does
>                 the task configuration or it updates the schedule
> 
>                  
> 
>                 fields would override the default behavior flag. That
>                 is, if the do-not-suppress flag was set for a given
>                 task, yet a Suppression message specifically listed that
>                 same task (or schedule containing the Task), the task
>                 indicates whether or not a Suppress message will
>                 suppress them.
> 
>                 when we have the more complex, optional Suppress
>                 message? (it lists specific Tasks or Schedules for
>                 suppression.)  
> 
>                 Treating the Boolean flag as meaning “do-not-suppress
>                 this Measurement Task”, my proposal is to basically keep
>                 the current text unaltered:
> 
>                                                                                                     
> 
> 
>                 In other words, if the Controller says “Suppress Task
>                 #213” then the MA checks the do-not-suppress flag for
>                 Task #213 and either throws an error or doesn’t start
>                 this Task. Similarly, if the Controller says “Suppress
>                 Schedule #49”, then the MA checks the do-not-suppress
>                 flag for Tasks in this schedule and either throws an
>                 error or doesn’t start any new Tasks in this schedule.
> 
>                  
> 
>                 I’ll also make clear that the Controller sets the
>                 do-not-suppress flag for a Task (it isn’t something that
>                 the MA decides about).
> 
>                  
> 
>                 Thanks
> 
>                 phil
> 
> 
> 
> 
>             Tel:  303.992.8952 [Call: 303.992.8952]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662 [Call: 925.281.0662]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>
> 
>         Tel:  303.992.8952 [Call: 303.992.8952]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662 [Call: 925.281.0662]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>
> 
>     Tel:  303.992.8952 [Call: 303.992.8952]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662 [Call: 925.281.0662]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>
> 
> Tel:  303.992.8952 [Call: 303.992.8952]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>  Fax:  925.281.0662 [Call: 925.281.0662]  <https://webmail.bt.com/owa/?ae=PreFormAction&a=ReplyAll&t=IPM.Note&id=RgAAAABWARhW9uvSEZooAAD4%2fpqUBwAJUlaC4%2bYvR48nJnYnCPX6ADZ2gQFyAACi4zfNt7xBRbAYub7o6z4NAED0unODAAAJ#>
>

---

From: KEN KO <[email-masked]>
Date: Wed, 11 Jun 2014 14:40:44 +0000

Phil, thank you for correcting my understanding of Trevor's proposed behavior. I'm going to summarize my understanding of each proposed definition for the flag, along with descriptive names for each and for the values they can take. Please correct me if I get anything wrong. Then, I'll attempt to justify my preference.

*** Definitions ***

"Default-Behavior" - The values are suppress-by-default and do-not-suppress-by-default. Either polarity may be over-ridden by an optional suppression list.

"Disable-Suppress" - The values are can-be-suppressed and do-not-suppress. A task with the can-be-suppressed flag is suppressed by default and the behavior may be over-ridden by an optional list. A task with the do-not-suppress flag may never be suppressed.

*** Justification ***

Here is a scenario:

An operator schedules periodic tests that include throughput (large volume of active measurement traffic), TWAMP (small volume of active measurement traffic), and a byte counter (no active measurement traffic). The desired response to a basic suppression message is:
Throughput	suppressed
TWAMP	not suppressed
Byte counter	not suppressed
This default suppression behavior is configured similarly with either flag.

The operator would also like to be able to suppress both throughput and TWAMP if necessary.

With Default-Behavior, this is done via a Suppress message with an optional list itemizing throughput and TWAMP. Suppression is terminated normally using the Unsuppress message. 

With Disable-Suppress, this requires reconfiguration of the Schedules, or reconfiguration of the Task flags followed by a Suppress message, in every MA. It then requires a second reconfiguration of every MA to restore the original behavior.

The only rationale I have seen for Disable-Suppress is to protect communication with the Controller, and multiple messages on this thread have indicated that there are better ways to accomplish that protection.

To be very clear - I strongly support Default-Behavior and I think Disable-Suppress needlessly limits the usefulness of the flag.

Thanks,
Ken

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 11 Jun 2014 15:59:10 +0000

+1
And one additional justification: Actually, the first value of the Disable-Suppress option is can-be-suppressed-AND-is suppressed-by-default. This is not the opposite of do-not-suppress. Flag (Boolean) values need to be opposites, or else they run into trouble. The flag's meaning in the proposed Disable-Suppress option is being overloaded by having non-opposing information expressed through it. To fix this, it would either be necessary to have 2 flags, or to use a multi-value parameter. 

Using 2 flags:
Disable-Suppress flag: suppression-allowed and suppression-not-allowed
Default-Behavior flag: suppress-by-default and do-not-suppress-by-default
If no optional list, then all Measurement Tasks with suppression-allowed AND suppress-by-default are suppressed. No others are suppressed.
If optional list, then all listed (directly or indirectly via a schedule) Measurement Tasks with suppression-allowed are suppressed. No others are suppressed.

Using multi-value parameter:
Suppress-Behavior: allowed values are suppression-allowed-AND-suppress-by-default; suppression-allowed-AND-do-not-suppress-by-default; suppression-not-allowed

I would have no problem with either of the above 2 possible approaches that do not overload the meaning of a Boolean flag by using non-opposite meanings of the 2 values. I have a problem with any approach that does overload the meaning of a Boolean flag.
Barbara

> -----Original Message-----
> Sent: Wednesday, June 11, 2014 10:41 AM
> To: Michael Faath; [email-masked]; [email-masked];
> Phil, thank you for correcting my understanding of Trevor's proposed
> behavior. I'm going to summarize my understanding of each proposed
> definition for the flag, along with descriptive names for each and for the
> values they can take. Please correct me if I get anything wrong. Then, I'll
> attempt to justify my preference.
> 
> *** Definitions ***
> 
> "Default-Behavior" - The values are suppress-by-default and do-not-
> suppress-by-default. Either polarity may be over-ridden by an optional
> suppression list.
> 
> "Disable-Suppress" - The values are can-be-suppressed and do-not-
> suppress. A task with the can-be-suppressed flag is suppressed by default
> and the behavior may be over-ridden by an optional list. A task with the do-
> not-suppress flag may never be suppressed.
> 
> *** Justification ***
> 
> Here is a scenario:
> 
> An operator schedules periodic tests that include throughput (large volume
> of active measurement traffic), TWAMP (small volume of active
> measurement traffic), and a byte counter (no active measurement traffic).
> The desired response to a basic suppression message is:
> Throughput	suppressed
> TWAMP	not suppressed
> With Default-Behavior, this is done via a Suppress message with an optional
> list itemizing throughput and TWAMP. Suppression is terminated normally
> using the Unsuppress message.
> 
> With Disable-Suppress, this requires reconfiguration of the Schedules, or
> reconfiguration of the Task flags followed by a Suppress message, in every
> MA. It then requires a second reconfiguration of every MA to restore the
> original behavior.
> 
> The only rationale I have seen for Disable-Suppress is to protect
> communication with the Controller, and multiple messages on this thread
> have indicated that there are better ways to accomplish that protection.
> 
> To be very clear - I strongly support Default-Behavior and I think Disable-
> Suppress needlessly limits the usefulness of the flag.
> 
> Thanks,
> Ken
>

---

From: <[email-masked]>
Date: Thu, 12 Jun 2014 08:51:50 +0100

OK - seems like I've lost this vote.

I will correct the information model to:
- add a "suppress-by-default" flag to the task configuration

If this flag is set then the general suppress message will default to all tasks with this flag set. If tasks or schedules are listed then those listed will be suppressed regardless of this flag.

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000 

>From: STARK, BARBARA H [mailto:[email-masked]]
>Sent: 11 June 2014 16:59
>To: KEN KO; Michael Faath; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R;
>And one additional justification: Actually, the first value of the Disable-Suppress
>option is can-be-suppressed-AND-is suppressed-by-default. This is not the
>opposite of do-not-suppress. Flag (Boolean) values need to be opposites, or else
>they run into trouble. The flag's meaning in the proposed Disable-Suppress option
>is being overloaded by having non-opposing information expressed through it. To
>fix this, it would either be necessary to have 2 flags, or to use a multi-value
>parameter.
>
>Using 2 flags:
>Disable-Suppress flag: suppression-allowed and suppression-not-allowed Default-
>Behavior flag: suppress-by-default and do-not-suppress-by-default If no optional
>list, then all Measurement Tasks with suppression-allowed AND suppress-by-
>default are suppressed. No others are suppressed.
>If optional list, then all listed (directly or indirectly via a schedule) Measurement
>Tasks with suppression-allowed are suppressed. No others are suppressed.
>
>Suppress-Behavior: allowed values are suppression-allowed-AND-suppress-by-
>default; suppression-allowed-AND-do-not-suppress-by-default; suppression-not-
>allowed
>
>I would have no problem with either of the above 2 possible approaches that do
>not overload the meaning of a Boolean flag by using non-opposite meanings of
>the 2 values. I have a problem with any approach that does overload the meaning
>of a Boolean flag.
>Barbara
>
>> definition for the flag, along with descriptive names for each and for
>> the values they can take. Please correct me if I get anything wrong.
>> Then, I'll attempt to justify my preference.
>>
>> *** Definitions ***
>>
>> suppress. A task with the can-be-suppressed flag is suppressed by
>> default and the behavior may be over-ridden by an optional list. A
>> task with the do- not-suppress flag may never be suppressed.
>>
>> *** Justification ***
>>
>> Here is a scenario:
>>
>> An operator schedules periodic tests that include throughput (large
>> volume of active measurement traffic), TWAMP (small volume of active
>> With Default-Behavior, this is done via a Suppress message with an
>> optional list itemizing throughput and TWAMP. Suppression is
>> terminated normally using the Unsuppress message.
>>
>> With Disable-Suppress, this requires reconfiguration of the Schedules,
>> or reconfiguration of the Task flags followed by a Suppress message,
>> in every MA. It then requires a second reconfiguration of every MA to
>> restore the original behavior.
>>
>> communication with the Controller, and multiple messages on this
>> thread have indicated that there are better ways to accomplish that protection.
>>
>> To be very clear - I strongly support Default-Behavior and I think
>> Disable- Suppress needlessly limits the usefulness of the flag.
>>
>> Thanks,
>> Ken
>>