Subject: [lmap] Question on information model - Suppression

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 13 May 2014 18:45:16 +0000

Trevor,

In the information model we defined suppression as:

object {
boolean ma-suppression-enabled;
[datetime ma-suppression-start;] // default: immediate
[datetime ma-suppression-end;] // default: indefinite
[string ma-suppression-task-names<0..*>;]
// default: all tasks if
// ma-suppression-task-names is empty
[string ma-suppression-schedule-names<0..*>;]
// default: all schedules if
// ma-suppression-schedule-names is empty
} ma-suppression-obj;

In the BBF review of the LMAP model - a question was asked regarding the relationship between tasks and schedules elements.

What are the rules:

1) If Tasks is non-empty and Schedules is non-empty

a. <TAC>: I think this would suppress the listed tasks with the listed schedules

2) If Tasks is empty and Schedules is non-empty

a. <TAC>: I think this would suppress all tasks for the listed schedules

3) If Tasks is non-empty and Schedules is empty

a. <TAC>: I think this would suppress listed tasks for all schedules of the task

4) If Tasks and Schedules are empty

a. <TAC>: I think this would suppress all tasks regardless of schedule

Is this the teams understanding?

Thanks,
tim

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Tue, 13 May 2014 20:45:47 +0000

Marc,

Inline <TAC1>

-----Original Message-----
From: marc.ibrahim [mailto:[email-masked]] 
Sent: Tuesday, May 13, 2014 2:42 PM
To: Carey, Timothy (Timothy); [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Tim,

> a. <TAC>: I think this would suppress the listed tasks with the listed schedules

While I agree with b. c. and d., a. seems unclear to me. Let me take a practical 
example:

Assume an MA has 3 tasks: T1, T2, and T3 with 2 schedules S1(T1,T2) and S2(T1,T2,T3).

If MA receives the message SUPPRESS([T1], [S1, S2]), I understand the following:
- MA will stop running T1 according to schedule S1 and S2
- MA will keep running T1 according to S2. 
- T2 and T3 are intact and still running according to S1 and S2. 

In conclusion, we just suppressed T1 from S1 and S2.

Is this right? <TAC1> No I would have thought T1 would be suppressed for S1 and S2; if there was an S3 for T1 then that would execute.

If yes, let's assume I want to send a suppress message asking MA to suppress T1 from S1 
and T2 from S1 and S2. If we send : SUPPRESS([T1,T2],[S1,S2]), it will delete T1 and T2 
from both schedules. We need then two suppress messages to do it:

1- SUPPRESS ([T1], [S1])      2- SUPPRESS ([T2], [S1,S2])

To be brief, since there is no association between tasks and schedules to suppress, more 
than one suppress messages would be needed to accomplish a given suppression scenario. 
To avoid this (if this is a pb), I think we should send suppression command as an array 
of pairs (Ti,Si).
(Ti,Si) => suppress Ti from Si
(Ti,*)=>suppress Ti from all Schedules
(*,Si)=>suppress schedule Si 

<TAC1> I would agree that a list of pairs would provide a more flexible approach - just wasn't the way it was currently modeled....

BR,

Marc.

On Tue, 13 May 2014 18:45:16 +0000, Carey, Timothy (Timothy) wrote

> 
> In the BBF review of the LMAP model - a question was asked regarding the 
> relationship between tasks and schedules elements.
> 
> What are the rules:
> 

--
Open WebMail Project (http://openwebmail.org)

---

From: "marc.ibrahim" <[email-masked]>
Date: Wed, 14 May 2014 00:02:29 +0300

Inline.
On Tue, 13 May 2014 20:45:47 +0000, Carey, Timothy (Timothy) wrote
> While I agree with b. c. and d., a. seems unclear to me. Let me take a 
> practical example:
> 
> If MA receives the message SUPPRESS([T1], [S1, S2]), I understand the 
> following: - MA will stop running T1 according to schedule S1 and S2 - MA will 
> keep running T1 according to S2. - T2 and T3 are intact and still running 
> according to S1 and S2.
> 
> Is this right? <TAC1> No I would have thought T1 would be suppressed for S1 
> and S2; if there was an S3 for T1 then that would execute.

Yes, in deed. Sorry, I added S2 in the suppress message and forgot to delete the 
erroneous sentence (MA will keep running T1 according to S2). So, I understand how it 
works.  

> 
> If yes, let's assume I want to send a suppress message asking MA to suppress 
> T1 from S1 and T2 from S1 and S2. If we send : SUPPRESS([T1,T2],[S1,S2]), it 
> will delete T1 and T2 from both schedules. We need then two suppress messages 
> to do it:
> 
> To be brief, since there is no association between tasks and schedules to 
> suppress, more than one suppress messages would be needed to accomplish a 
> given suppression scenario. To avoid this (if this is a pb), I think we should 
> send suppression command as an array of pairs (Ti,Si).
> <TAC1> I would agree that a list of pairs would provide a more flexible 
> approach - just wasn't the way it was currently modeled....
> 

Ok

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 May 2014 23:46:56 +0200

> Is this the teams understanding?

Yes on 2) and 3) and 4). Concerning 1), I think the semantics are not
spelled out this clearly is something that needs fixing. The question
is what the semantics should be. One possible interpretation (the one
you suggest above) is that the intersection would be suppressed.
Another possible interpretation is that the union would be suppressed,
that is, it supresses all listed tasks and all tasks triggered by for
the listed schedules. I do not know what the 'right' answer is. Of
course, the 'union' interpretation can always achieved by having two
ma-suppression-objs (one listing the tasks, the second listing the
schedules). This makes your interpretation somewhat appealing. I am
not sure, however, whether this can make things tricky. Another option
could also be to disallow 1).

I am not sure what to do but I agree that this needs to be worked out,
so thanks for bringing this up.

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 May 2014 07:52:12 +0200

On Wed, May 14, 2014 at 01:22:55AM +0300, marc. ibrahim wrote:
> 
> ma-suppression-task-names<0..*> and
> ma-suppression-schedule-names<0..*> are strings containing names of
> tasks and schedules. If we just allow to have the same name multiple
> times, a pairing association could be done between tasks without
> changing the information model.
>
> For example, ma-suppression-task-names = [T1 T1 T2 T2 T3 *] and
> ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that T1
> will be suppressed from S1 and S2, T2 from S1 and S2, T3 from all
> schedules, and schedule S4 will be suppressed. Does this change the
> information model Tim?

I do not think this is needed since you can have multiple suppression
objects. But defining the intersection of

  ma-suppression-task-names = [T1 T2]
  ma-suppression-schedule-names = [S1 S2]

may not be that clear. The union is clear, suppress tasks T1 and T2
and anything started by S1 and S2. Is the intersection interpretation
suppress any T1 started by S1, any T2 started by S1, any T1 started by
S2, any T2 started by S2? This is not really an intersection - a
strict intersection interpretation would likely lead to an empty set.

/js

---

From: "marc.ibrahim" <[email-masked]>
Date: Wed, 14 May 2014 09:59:36 +0300

On Wed, 14 May 2014 07:52:12 +0200, Juergen Schoenwaelder wrote
> strict intersection interpretation would likely lead to an empty set.

No, this is my proposition. Intersection as I understood from Tim, is different. 

Let's have a general suppression object:

ma-suppression-task-names = [T1 ... Tn]
ma-suppression-schedule-names = [S1 ... Sm]

Intersection means:  Ti will be suppressed from any schedule S1 ... Sm starting Ti.

Union means: Tasks T1 to Tn are all suppressed (from all MA schedules, isn't it JS?) and 
all tasks started by S1 to Sm should be suppressed too.

Pairing: m=n. Ti suppressed from Si.

I see the intersection (or another term) definition is as clear as union IMO. If I 
understood you well JS, I see that union cannot perform all suppression possibilities. 
For example, how to suppress only a subset from a given schedule?
Intersection can do it with one or more suppression objects.
Pairing solution needs only one object to do any suppression combination.

BR,

Marc.

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 May 2014 09:37:58 +0200

> Pairing solution needs only one object to do any suppression combination.

I do not like pairing. I am fine with intersection or alternatively to
remove the capability to have both a task list and a schedule list in
a suppression. I think we should not over engineer suppression.

/js

---

From: <[email-masked]>
Date: Wed, 14 May 2014 10:01:47 +0100

I also would not over engineer suppression. I'd either interpret as the Union, or else not allow both a task and schedule list in a suppression.

> > Union means: Tasks T1 to Tn are all suppressed (from all MA
> schedules,
> > isn't it JS?) and all tasks started by S1 to Sm should be suppressed
> too.
> >
> > I see the intersection (or another term) definition is as clear as
> > union IMO. If I understood you well JS, I see that union cannot
> perform all suppression possibilities.

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 14 May 2014 11:33:26 +0000

I am open to any of the approaches for this combination; just need an answer as I am updating the BBF data model...:-)

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 14 May 2014 11:37:47 +0000

Juergen,

You cannot as I read the text have multiple suppression objects. Did I miss something.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2014 12:52 AM
To: marc. ibrahim
Cc: Carey, Timothy (Timothy); [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 May 2014 14:09:20 +0200

Yes, I stand corrected.

I think I am personally leaning towards allowing multiple suppression
objects in order to keep the complexity of each suppression object
down to a basic minimum.

/js

---

From: KEN KO <[email-masked]>
Date: Wed, 14 May 2014 13:06:21 +0000

Adding +1 to the comments cautioning us to avoid over-engineering suppression.

Per the framework, suppression is "used if the measurement system wants to eliminate inessential traffic, because there is some unexpected network issue for example." It provides a means of doing so without updating the existing measurement schedules, as a temporary relief measure in which measurements are disrupted by definition.

There is no need for complete flexibility in the suppression mechanism (e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purpose, because you can always modify the schedules to get that level of control. When you consider that every option adds complexity to the MA, there is a case to be made for simplifying rather than complicating suppression. 

WRT the existing ambiguity: I prefer barring the two fields from being used together as that will be simplest for the MA. Union or Intersection are also acceptable as fixed definitions (not options). I think adding pairing or multiple suppression objects would be a mistake.

Best regards,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 14, 2014 8:09 AM
To: Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Yes, I stand corrected.

I think I am personally leaning towards allowing multiple suppression objects in order to keep the complexity of each suppression object down to a basic minimum.

/js

On Wed, May 14, 2014 at 11:37:47AM +0000, Carey, Timothy (Timothy) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 15 May 2014 14:20:54 +0000

So I would like close on a consensus. I added the union as the first option which seemed to have the most consensus. Do we have consensus on this?

What are the rules:
1) If Tasks is non-empty and Schedules is non-empty: suppress the listed tasks and the listed  schedules as an union of the tasks and schedules

2) If Tasks is empty and Schedules is non-empty - suppress all tasks for the listed 
Schedules

3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for all schedules 
of the task

4) If Tasks and Schedules are empty: suppress all tasks regardless of schedule

Thanks,
Tim

-----Original Message-----
From: KEN KO [mailto:[email-masked]] 
Sent: Wednesday, May 14, 2014 8:06 AM
To: Juergen Schoenwaelder; Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Best regards,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 14, 2014 8:09 AM
To: Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Yes, I stand corrected.

/js

---

From: KEN KO <[email-masked]>
Date: Thu, 15 May 2014 14:23:46 +0000

That looks good to me. 
Ken

-----Original Message-----
From: Carey, Timothy (Timothy) [mailto:[email-masked]] 
Sent: Thursday, May 15, 2014 10:21 AM
To: KEN KO; Juergen Schoenwaelder
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

What are the rules:

2) If Tasks is empty and Schedules is non-empty - suppress all tasks for the listed Schedules

3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for all schedules of the task

Thanks,
Tim

-----Original Message-----
From: KEN KO [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 8:06 AM
To: Juergen Schoenwaelder; Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Best regards,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 14, 2014 8:09 AM
To: Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Yes, I stand corrected.

/js

---

From: KEN KO <[email-masked]>
Date: Thu, 15 May 2014 14:30:51 +0000

Modifying my own reply. #4, if Tasks and Schedules are both empty, isn't the default action applied to Active measurement tasks, with the effect on Passive tasks undefined? That is what the framework draft says but the information model omits the word "active." The two documents need to be consistent.

-----Original Message-----
From: KEN KO 
Sent: Thursday, May 15, 2014 10:24 AM
To: 'Carey, Timothy (Timothy)'; Juergen Schoenwaelder
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

That looks good to me. 
Ken

-----Original Message-----
From: Carey, Timothy (Timothy) [mailto:[email-masked]]
Sent: Thursday, May 15, 2014 10:21 AM
To: KEN KO; Juergen Schoenwaelder
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

What are the rules:

Thanks,
Tim

-----Original Message-----
From: KEN KO [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 8:06 AM
To: Juergen Schoenwaelder; Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Best regards,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 14, 2014 8:09 AM
To: Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Yes, I stand corrected.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 15 May 2014 14:34:54 +0000

A month or so ago we identified that the Test registry wouldn't include a set of test method descriptors for handling test behaviors with things like Cross traffic.
  Do we as a group, or any individuals here have suggestions on how to add that "behavior per test" for including test method / behavior strings outside of the test attributes themselves?

 I this is a fairly significant gap so before I started pondering ways I thought I'd ask if I missed a group direction on this one 

Thanks,
Mike

---

From: "Marc Ibrahim" <[email-masked]>
Date: Thu, 15 May 2014 17:52:11 +0300

Ok for union interpretation. 

The section (5.3.1.1) of the framework states that a suppression can
optionally include a demand to stop on-going active measurements. I don't
see this option in the suppression object.

BR,

Marc.

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Carey, Timothy
(Timothy)
Sent: Thursday, May 15, 2014 5:21 PM
To: KEN KO; Juergen Schoenwaelder
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

So I would like close on a consensus. I added the union as the first option
which seemed to have the most consensus. Do we have consensus on this?

What are the rules:
1) If Tasks is non-empty and Schedules is non-empty: suppress the listed
tasks and the listed  schedules as an union of the tasks and schedules

2) If Tasks is empty and Schedules is non-empty - suppress all tasks for the
listed Schedules

3) If Tasks is non-empty and Schedules is empty: suppress listed tasks for
all schedules of the task

4) If Tasks and Schedules are empty: suppress all tasks regardless of
schedule

Thanks,
Tim

-----Original Message-----
From: KEN KO [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 8:06 AM
To: Juergen Schoenwaelder; Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Adding +1 to the comments cautioning us to avoid over-engineering
suppression.

Per the framework, suppression is "used if the measurement system wants to
eliminate inessential traffic, because there is some unexpected network
issue for example." It provides a means of doing so without updating the
existing measurement schedules, as a temporary relief measure in which
measurements are disrupted by definition.

There is no need for complete flexibility in the suppression mechanism
(e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this
purpose, because you can always modify the schedules to get that level of
control. When you consider that every option adds complexity to the MA,
there is a case to be made for simplifying rather than complicating
suppression. 

WRT the existing ambiguity: I prefer barring the two fields from being used
together as that will be simplest for the MA. Union or Intersection are also
acceptable as fixed definitions (not options). I think adding pairing or
multiple suppression objects would be a mistake.

Best regards,
Ken

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 14, 2014 8:09 AM
To: Carey, Timothy (Timothy)
Cc: marc. ibrahim; [email-masked]
Subject: Re: [lmap] Question on information model - Suppression

Yes, I stand corrected.

I think I am personally leaning towards allowing multiple suppression
objects in order to keep the complexity of each suppression object down to a
basic minimum.

/js

---

From: <[email-masked]>
Date: Thu, 15 May 2014 16:09:28 +0100

Currently ma-suppression-obj contains the Boolean ma-suppression-stop-ongoing-tasks.

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: lmap [mailto:[email-masked]] On Behalf Of Marc Ibrahim
>Sent: 15 May 2014 15:52
>To: 'Carey, Timothy (Timothy)'; 'KEN KO'; 'Juergen Schoenwaelder'
>Cc: [email-masked]
>The section (5.3.1.1) of the framework states that a suppression can optionally
>include a demand to stop on-going active measurements. I don't see this option
>in the suppression object.
>
>BR,
>
>Marc.
>
>
>
>So I would like close on a consensus. I added the union as the first option which
>seemed to have the most consensus. Do we have consensus on this?
>
>
>What are the rules:
>1) If Tasks is non-empty and Schedules is non-empty: suppress the listed tasks and
>the listed  schedules as an union of the tasks and schedules
>
>eliminate inessential traffic, because there is some unexpected network issue for
>example." It provides a means of doing so without updating the existing
>measurement schedules, as a temporary relief measure in which measurements
>are disrupted by definition.
>
>There is no need for complete flexibility in the suppression mechanism (e.g.,
>pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve this purpose,
>because you can always modify the schedules to get that level of control. When
>you consider that every option adds complexity to the MA, there is a case to be
>made for simplifying rather than complicating suppression.
>
>acceptable as fixed definitions (not options). I think adding pairing or multiple
>suppression objects would be a mistake.
>
>Best regards,
>Ken
>
>I think I am personally leaning towards allowing multiple suppression objects in
>order to keep the complexity of each suppression object down to a basic
>minimum.
>
>/js
>

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 15 May 2014 17:01:53 +0000

Trevor,

The latest published draft (draft-ietf-lmap-information-model-00) has
   object {

BR,
Tim
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 15, 2014 10:09 AM
To: [email-masked]; Carey, Timothy (Timothy); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Trevor.

Trevor Burbridge

---

From: <[email-masked]>
Date: Mon, 19 May 2014 09:01:58 +0100

Sorry, my mistake - the additional parameter was agreed to be added in London, so will appear in revision 01.

Trevor.

Trevor Burbridge

>Sent: 15 May 2014 18:02
>To: Burbridge,T,Trevor,TUB8 R; [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]
>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.

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 19 May 2014 12:15:06 +0000

Ok - no worries;

So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop all active and passive measurements, correct while the schedule and tasks entities only work on active measurements, correct?

If so - I will document that as well as the union approach when schedules and tasks are non-empty. 

BR,
Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 19, 2014 3:02 AM
To: Carey, Timothy (Timothy); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [lmap] Question on information model - Suppression

Trevor.

Trevor Burbridge

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: Carey, Timothy (Timothy) 
>[mailto:[email-masked]]
>Sent: 15 May 2014 18:02
>To: Burbridge,T,Trevor,TUB8 R; [email-masked]; 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>To: [email-masked]; Carey, Timothy (Timothy); 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>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.
>Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
>England no: 1800000
>
>
>>optionally include a demand to stop on-going active measurements. I 
>>don't see this option in the suppression object.
>>
>>BR,
>>
>>Marc.
>>
>>
>>
>>So I would like close on a consensus. I added the union as the first 
>>option which seemed to have the most consensus. Do we have consensus on this?
>>
>>
>>What are the rules:
>>1) If Tasks is non-empty and Schedules is non-empty: suppress the 
>>listed tasks
>and
>>Per the framework, suppression is "used if the measurement system 
>>wants to eliminate inessential traffic, because there is some 
>>unexpected network issue
>for
>>example." It provides a means of doing so without updating the 
>>(e.g., pairing Task 1 in Schedule 2 and Task 3 in Schedule 4) to serve 
>>this purpose, because you can always modify the schedules to get that 
>>level of control. When you consider that every option adds complexity 
>>to the MA, there is a case to be made for simplifying rather than complicating suppression.
>>
>>WRT the existing ambiguity: I prefer barring the two fields from being 
>>used together as that will be simplest for the MA. Union or 
>>Intersection are also acceptable as fixed definitions (not options). I 
>>think adding pairing or multiple suppression objects would be a mistake.
>>
>>Best regards,
>>Ken
>>
>>> You cannot as I read the text have multiple suppression objects. Did 
>>> I
>>miss something.
>>>
>>> > ma-suppression-schedule-names<0..*> are strings containing names 
>>> > of tasks and schedules. If we just allow to have the same name 
>>> > multiple times, a pairing association could be done between tasks 
>>> > without changing the information model.
>>> >
>>> > ma-suppression- schedule-names [S1 S2 S1 S2 * S4] would mean that 
>>> > T1 will be suppressed from S1 and S2, T2 from S1 and S2, T3 from 
>>> > all schedules, and schedule S4 will be suppressed. Does this 
>>> > change the information model Tim?
>>>
>>> I do not think this is needed since you can have multiple 
>>> suppression objects. But defining the intersection of
>>>
>>> and anything started by S1 and S2. Is the intersection 
>>> interpretation suppress any T1 started by S1, any T2 started by S1, 
>>> any T1 started by S2, any T2 started by S2? This is not really an 
>>> intersection - a strict intersection interpretation would likely lead to an empty set.
>>>
>>> /js
>>>
>>> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 May 2014 14:18:29 +0200

> So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop all active and passive measurements, correct while the schedule and tasks entities only work on active measurements, correct?

Why? What is the value of restricting this? I think we already
discussed some weeks ago that there may be hybrid things as well.

What is wrong with simply suppressing tasks irrespective of their
nature?

/js

---

From: <[email-masked]>
Date: Mon, 19 May 2014 13:28:47 +0100

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.

Trevor Burbridge

>Sent: 19 May 2014 13:15
>So then stop ongoing tasks (ma-suppression-stop-ongoing-tasks) will stop all
>active and passive measurements, correct while the schedule and tasks entities
>only work on active measurements, correct?
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 May 2014 20:23:41 +0200

> 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 t…

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

---

From: "marc.ibrahim" <[email-masked]>
Date: Mon, 19 May 2014 22:10:44 +0300

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

---

From: <[email-masked]>
Date: Tue, 20 May 2014 09:07:04 +0100

>Sent: 19 May 2014 19:24
>To: Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
[...]
>ought to be simple and used only in rare situations...

To do what you suggest (tasks not involved in measurements are always not suppressible) would need some sort of flag or classification. The MA needs some way to decide whether it  is a measurement task. The only question really is whether it is it the registry entry (not changeable for different deployments) or in the task configuration.

Trevor.

---

From: <[email-masked]>
Date: Tue, 20 May 2014 09:14:16 +0100

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

>Sent: 19 May 2014 20:11
>To: Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; [email-masked]; [email-masked]
>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,
>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.
>
>
>

---

From: Charles Cook <[email-masked]>
Date: Tue, 20 May 2014 08:58:17 -0600

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

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]

---

From: <[email-masked]>
Date: Tue, 20 May 2014 16:52:09 +0100

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

>From: Charles Cook [mailto:[email-masked]]
>Sent: 20 May 2014 15:58
>Cc: [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>> 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.
>>
>> - BUT the tasks run in the controller communication schedule are exempt from
>suppression. i.e. suppression only affects the Instruction schedules.
>>
>> Trevor.
>>
>> Trevor Burbridge
>>
>>> active/passive/non-measurement tasks or whether the suppression should
>stop
>>> the task
>>> configuration I am leaning towards having an arbitrary "suppressible" flag
>which
>>> would

---

From: Charles Cook <[email-masked]>
Date: Tue, 20 May 2014 12:02:06 -0600

Thanks.  This helps.  I can generally agree with this approach.  I do,
however, have one question...

What would be the intended approach to deal with a DOS attack by a rogue
MA(s) on a Controller?  Or do we treat that as an exception case that is
out of scope since a hacker could ignore a suppression and perform a DOS
regardless of the protocol?  I suppose the Controller needs to have a
strategy on how to protect itself in such a situation.

Charles

-- 

Charles Cook 
Principal Architect
Network

---

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

On Tue, May 20, 2014 at 09:07:04AM +0100, [email-masked] wrote:
> 
> To do what you suggest (tasks not involved in measurements are
> always not suppressible) would need some sort of flag or
> classification. The MA needs some way to decide whether it is a
> measurement task. The only question really is whether it is it the
> registry entry (not changeable for different deployments) or in the
> task configuration.

I assume an implementation knows the difference between measurement
tasks and tasks organizing the information flow with the controller
and collector. In other words, the distinction between measurement
tasks and infrastructure tasks is kind of hard-wired and not something
configurable via instructions.

/js