Subject: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

From: <[email-masked]>
Date: Mon, 2 Jun 2014 16:09:41 +0100

Following up on the thread (after holidays)

current definitions:-

Passive Measurement Method (Task): A Measurement Method (Task) in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic.

Active Measurement Task: A Measurement Task in which a Measurement Agent creates or receives Active Measurement Traffic, by coordinating with one or more other Measurement Agents or Measurement Peers using protocols outside the initial LMAP work scope.

--

My view is that the Task is about what the MA does. To answer Barbara's quiz question, it is possible to define the activity as two small Tasks or one larger integrated Task.

I can understand the desire to talk 'holistically' about the whole measurement system. But looking at say Fig A4 in http://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The passive monitor is an MA running Passive Task. It observes existing traffic from entities that are, from its perspective, MPs. This traffic could be user traffic or actually generated by another (Active) Task. As far as the function labelled Passive Monitor is concerned, it doesn't care.

I thought Barbara's example of UDP echo makes the good point that the client and server ends have a different role so may well have to point to different registry entries.

I agree with Al that passive and active are two end points of a continuum and there are techniques in-between the extremes (like Nalini's colour marking of pkts). I'd prefer to leave it to ippm to work on the subtleties - as far as lmap is concerned we know that there's a registry of tests, which ippm is proposing to sub-divide into active and passive. Maybe later ippm will decide which sub-registry in-between tests should be in, or that a new registry is needed, or whatever. I think lmap can live with this slight uncertainty.

So I think it's better for the definition of Passive to stick with "observes".

Greg didn't like the formulation "Active Measurement Method (Task)" - if I remember, he thought it was unclear and wanted it split into two definitions. Since we already have definitions for Measurement Method and Measurement Task, I actually think it's unnecessary to distinguish Method & Task in the Passive & Active definitions. So I suggest deleting the 'Active Measurement Method' definition, and similarly making the Passive definition just about 'Passive Measurement Task'.

Greg also didn't like the way the Active definition talks about coordination. I think the point is: whilst some Active Tasks involve the MA coordinating with other MPs (examples A1 and A2 in the Appendix - eg web server responds to client request), in others (example A3) the Controller controls the other MA and the first MA just sends it traffic (the MAs don't really coordinate with each other).

--

Proposal:-

In the Intro, add to the paragraph about Active & Passive Tasks:

There may also be Measurement Tasks that are intermediate between Passive and Active ones; consideration is outside the initial LMAP work scope.

In terminology, tweak the definitions:-

Passive Measurement Task: A Measurement Task in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic.

Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordinates with them using protocols outside the initial LMAP work scope.

Best wishes

phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 17:22:49 +0200

> Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and per…

And do we remove '(active|passive) measurement method' and do we try
to get rid nof 'measurement method' altogether (so that IPPM can
define and use this term in a way they find it most useful)?

/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: Greg Mirsky <[email-masked]>
Date: Mon, 2 Jun 2014 10:04:03 -0700

Hi Juergen,
I think that LMAP Framework may not need to define what Measurement Method
is and leave it to IPPM, perhaps in its Performance Registry work, to
define. But I believe that the LMAP Framework will have to use the
Measurement Method and then reference the definition given by IPPM. That
may cause document dependency and delay progress of the LMAP Framework.

Regards,
Greg

On Mon, Jun 2, 2014 at 8:22 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > There may also be Measurement Tasks that are intermediate between
> Passive and Active ones; consideration is outside the initial LMAP work
> scope.
> >
> >
> >
> > Passive Measurement Task: A Measurement Task in which a Measurement
> Agent observes existing traffic but does not inject Active Measurement
> Traffic.
> >
> >
> >
> > Active Measurement Task: A Measurement Task in which a Measurement Agent
> sends Active Measurement Traffic to, or receives it from, one or more other
> Measurement Agents or Measurement Peers, and perhaps coordinates with them
> using protocols outside the initial LMAP work scope.
> >
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 2 Jun 2014 13:13:03 -0400

below...
________________________________________
From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: Monday, June 02, 2014 11:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

/js

[acm]
The distinction between active and passive measurement exists in the framework
(primarily) to support the privacy considerations section (where it matters quite a lot,
and in an early draft, the definitions only appeared in that section).
I think the definitions above are sufficient information for the privacy section.

Al

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 2 Jun 2014 10:34:06 -0700

Hi Phil,
thank you for the good capture of my comments. "Didn't like" may be little
too strong to characterize my POV and sorry if it came across that way.
Please find my notes in-line and tagged by GIM>>.

Regards,
Greg

On Mon, Jun 2, 2014 at 8:09 AM, <[email-masked]> wrote:

> Passive Measurement Method (Task): A Measurement Method (Task) in which a
> Measurement Agent observes existing traffic but does not inject Active
> Measurement Traffic.
>
>
>
> creates or receives Active Measurement Traffic, by coordinating with one or
> more other Measurement Agents or Measurement Peers using protocols outside
> the initial LMAP work scope.
>
>
>
> --
>
> My view is that the Task is about what the MA does. To answer Barbara’s
> quiz question, it is possible to define the activity as two small Tasks or
> one larger integrated Task.
>
>
>
> I can understand the desire to talk ‘holistically’ about the whole
> measurement system. But looking at say Fig A4 in
> http://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The
> passive monitor is an MA running Passive Task. It observes existing traffic
> from entities that are, from its perspective, MPs. This traffic could be
> user traffic or actually generated by another (Active) Task. As far as the
> function labelled Passive Monitor is concerned, it doesn’t care.
>
>
>
> I thought Barbara’s example of UDP echo makes the good point that the
> client and server ends have a different role so may well have to point to
> different registry entries.
>
>
>
> I agree with Al that passive and active are two end points of a continuum
> and there are techniques in-between the extremes (like Nalini’s colour
> marking of pkts). I’d prefer to leave it to ippm to work on the subtleties
> – as far as lmap is concerned we know that there’s a registry of tests,
> which ippm is proposing to sub-divide into active and passive. Maybe later
> ippm will decide which sub-registry in-between tests should be in, or that
> a new registry is needed, or whatever. I think lmap can live with this
> slight uncertainty.
>
GIM>> As noted in mail to Juergen, LMAP Framework has to use Measurement
Method, as that is what being referenced by the Measurement Controller.
Perhaps we can shy away from differentiation between Active and Passive
methods.

> So I think it’s better for the definition of Passive to stick with
> “observes”.
>
>
>
>
>
> Greg didn’t like the formulation “Active Measurement Method (Task)” – if I
> remember, he thought it was unclear and wanted it split into two
> definitions. Since we already have definitions for Measurement Method and
> Measurement Task, I actually think it’s unnecessary to distinguish Method &
> Task in the Passive & Active definitions. So I suggest deleting the ‘Active
> Measurement Method’ definition, and similarly making the Passive definition
> just about ‘Passive Measurement Task’.
>
>
>
> Greg also didn’t like the way the Active definition talks about
> coordination. I think the point is: whilst some Active Tasks involve the MA
> coordinating with other MPs (examples A1 and A2 in the Appendix – eg web
> server responds to client request), in others (example A3) the Controller
> controls the other MA and the first MA just sends it traffic (the MAs don’t
> really coordinate with each other).
>
>
>
> --
>
>
>
> Proposal:-
>
> There may also be Measurement Tasks that are intermediate between Passive
> and Active ones; consideration is outside the initial LMAP work scope.
>
>
>
> Passive Measurement Task: A Measurement Task in which a Measurement Agent
> observes existing traffic but does not inject Active Measurement Traffic.
>
> GIM>> I think that "observes" is not the same as "collect information
> off". Can it be "... in which a Measurement Agent collects information off
> existing traffic ..."? I think that a Measurement Agent may coordinate its
> actions in performing Passive Measurement Task with other Measurement
> Agents/Peers. More on it below.
>
> using protocols outside the initial LMAP work scope
>
GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And I'd
> like to discuss new Measurement Domain object defined as:
>
The community of Measurement Agents and Measurement Peers that cooperate in
> performing a Measurement Task, whether Active or Passive, present a
> Measurement Domain. Coordination protocol(s) used within Measurement Domain
> are outside of the initial LMAP work scope.
>
Then in definitions of Active/Passive Measurement Task in the LMAP
Framework we can use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent
collects information off existing traffic within its Measurement Domain.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 2 Jun 2014 20:31:50 +0000

In-line.
Barbara

GIM>> As noted in mail to Juergen, LMAP Framework has to use Measurement Method, as that is what being referenced by the Measurement Controller. Perhaps we can shy away from differentiation between Active and Passive methods.

<bhs> I disagree that the Measurement Controller is referencing the “holistic technique”. I think the Measurement Controller is only referencing the specific role within that holistic technique that the Controller needs to instruct an MA to do. Assuming a single Controller communicates with all points of a holistic technique doesn’t scale. So we can’t preclude the possibility that different Controllers communicate with different MAs, and that some Operations System communicates with all Controllers in order to coordinate them. Nothing in the current LMAP framework architecture either assumes or requires the Controller to have a holistic view. Similarly, a single Collector doesn’t have to collect all results for a holistic technique. In framework Figure 1, the Collector feeds the repository. As long as all the collected data makes it to the repository (even if it all comes from different Collectors), the data analysis tools are expected to be able to combine the results that were part of a holistic technique.

The operator of the measurement framework needs to have the holistic view. None of the defined LMAP elements needs such a view. I don’t consider the registry to be an LMAP element, since it’s coming from IPPM. But even there, the requirement that LMAP places upon the registry, is for the registry to provide enough granularity that the Controller knows the inputs needed for the particular role an MA needs to play in a holistic technique. The registry URL that is associated with a Measurement Task really needs to be specific to the MA’s role in the holistic technique.

--

GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And I'd like to discuss new Measurement Domain object defined as:

The community of Measurement Agents and Measurement Peers that cooperate in performing a Measurement Task, whether Active or Passive, present a Measurement Domain. Coordination protocol(s) used within Measurement Domain are outside of the initial LMAP work scope.

<bhs> I disagree with this use of Measurement Task. Measurement Task is specific to a MA. If multiple MAs and MPs cooperate in an instantiation of a holistic technique, then each MA and MP is performing a Measurement Task. If IPPM takes over this term, too, and tries to make it holistic, I think that will cause way too much rework in LMAP to create a new term for the instantiation of an MA-specific role and replace Measurement Task in all instances with the new term. If IPPM needs a term for the instantiation of a holistic technique, it should invent a new term. I’m also not sure this new term “Measurement Domain” is needed, or that I would call what you describe a Measurement Domain. Framework already talks about operational domain and LMAP domain. LMAP domain is “the system of functions deployed by a single organisation [to do large-scale measurements]”. To use the word “domain” to describe just the MAs involved in a single instantiation of a holistic technique seems to not be a good use of “domain” to me.

Barbara

---

From: Vero Zheng <[email-masked]>
Date: Tue, 3 Jun 2014 07:38:11 +0000

Hi Phil,

Please see inline.

Proposal:-

GIM>> I think that "observes" is not the same as "collect information off". Can it be "... in which a Measurement Agent collects information off existing traffic ..."? I think that a Measurement Agent may coordinate its actions in performing Passive Measurement Task with other Measurement Agents/Peers. More on it below.
Vero>>I think Greg’s suggestion of using “collect information off” is a better idea. Its more generic than “observes”.

Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordinates with them using protocols outside the initial LMAP work scope
GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"?

Vero>> the current definition of Active Measurement Traffic:  the packet(s) generated in order to  execute an Active Measurement Task.
As Mach pointed out in his note, technologies like ITU-T Y.1731, RFC 6374 are generating OAM packets, which delimiting the existing packets and carrying the information of existing traffic, e.g. packet counts and timestamps. These measurement method generate packets in order to execute an measurement task, but will you consider them as Active Measurement Method? My answer will be NO. Even though OAM packets is generated, but the measurement task is to collect the information of the existing traffic, not the information of the generated packets.

I agree with Mach that it's better from the tested object point of view (e.g., for a measurement task, whether the tested object is the existing traffic or injected traffic) to define what Passive and Active measurement method/task/traffic is.

There may also be Measurement Tasks that are intermediate between Passive and Active ones; consideration is outside the initial LMAP work scope.
Vero>> If we tweak the definitions carefully, we may don’t need to exclude any measurement tasks outside scope.

Cheers, Vero

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, June 03, 2014 1:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

Hi Phil,
thank you for the good capture of my comments. "Didn't like" may be little too strong to characterize my POV and sorry if it came across that way. Please find my notes in-line and tagged by GIM>>.
Regards,
Greg

On Mon, Jun 2, 2014 at 8:09 AM, <[email-masked]<mailto:[email-masked]>> wrote:

current definitions:-

--

My view is that the Task is about what the MA does. To answer Barbara’s quiz question, it is possible to define the activity as two small Tasks or one larger integrated Task.

I can understand the desire to talk ‘holistically’ about the whole measurement system. But looking at say Fig A4 in http://tools.ietf.org/html/draft-ietf-lmap-framework-05#section-10 The passive monitor is an MA running Passive Task. It observes existing traffic from entities that are, from its perspective, MPs. This traffic could be user traffic or actually generated by another (Active) Task. As far as the function labelled Passive Monitor is concerned, it doesn’t care.

I thought Barbara’s example of UDP echo makes the good point that the client and server ends have a different role so may well have to point to different registry entries.

I agree with Al that passive and active are two end points of a continuum and there are techniques in-between the extremes (like Nalini’s colour marking of pkts). I’d prefer to leave it to ippm to work on the subtleties – as far as lmap is concerned we know that there’s a registry of tests, which ippm is proposing to sub-divide into active and passive. Maybe later ippm will decide which sub-registry in-between tests should be in, or that a new registry is needed, or whatever. I think lmap can live with this slight uncertainty.
GIM>> As noted in mail to Juergen, LMAP Framework has to use Measurement Method, as that is what being referenced by the Measurement Controller. Perhaps we can shy away from differentiation between Active and Passive methods.

So I think it’s better for the definition of Passive to stick with “observes”.

Greg didn’t like the formulation “Active Measurement Method (Task)” – if I remember, he thought it was unclear and wanted it split into two definitions. Since we already have definitions for Measurement Method and Measurement Task, I actually think it’s unnecessary to distinguish Method & Task in the Passive & Active definitions. So I suggest deleting the ‘Active Measurement Method’ definition, and similarly making the Passive definition just about ‘Passive Measurement Task’.

Greg also didn’t like the way the Active definition talks about coordination. I think the point is: whilst some Active Tasks involve the MA coordinating with other MPs (examples A1 and A2 in the Appendix – eg web server responds to client request), in others (example A3) the Controller controls the other MA and the first MA just sends it traffic (the MAs don’t really coordinate with each other).

--

Proposal:-

GIM>> I think that "observes" is not the same as "collect information off". Can it be "... in which a Measurement Agent collects information off existing traffic ..."? I think that a Measurement Agent may coordinate its actions in performing Passive Measurement Task with other Measurement Agents/Peers. More on it below.

Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordinates with them using protocols outside the initial LMAP work scope

The community of Measurement Agents and Measurement Peers that cooperate in performing a Measurement Task, whether Active or Passive, present a Measurement Domain. Coordination protocol(s) used within Measurement Domain are outside of the initial LMAP work scope.
Then in definitions of Active/Passive Measurement Task in the LMAP Framework we can use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent collects information off existing traffic within its Measurement Domain.

Best wishes

phil

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

---

From: <[email-masked]>
Date: Wed, 4 Jun 2014 16:34:12 +0100

Proposal:-

[phil] I don't really understand what difference you're getting at - what meaning do you want to convey with "collect information" that differs from "observes"?

[phil] yes, Active Measurement Traffic is what you could call test traffic ["Active Measurement Traffic: the packet(s) generated in order to execute an Active Measurement Task."]

[phil] re measurement domain - i can see this may be a useful concept, but i don't think we've needed this term yet in lmap. given how tricky agreeing terminology is, can we delay defining this term until we're sure we need it.

thanks
phil

---

From: <[email-masked]>
Date: Wed, 4 Jun 2014 16:37:31 +0100

[phil] ok, let's shorten to "There may also be Measurement Tasks that are intermediate between Passive and Active ones"

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 4 Jun 2014 08:54:25 -0700 (PDT)

BTW,  I wanted to give you a heads-up that the team which has been working on the Passive Framework for IPPM (draft-zheng-ippm-framework-passive-00) will be posting our draft on June 11th.

We will have discussion and definition of many of the terms involved in Passive Monitoring from the IPPM point of view.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Sent: Wednesday, June 4, 2014 8:37 AM
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 4 Jun 2014 09:40:22 -0700

Hi Phil,
thank you for your prompt response to my comments.
if I compare common interpretations of "observe" and "collect":
ob·serve* verb* \əb-ˈzərv\

: to watch and sometimes also listen to (someone or something) carefully

: to see and notice (someone or something)

: to make a comment about something you notice

vs.
col·lect* verb* \kə-ˈlekt\

: to get (things) from different places and bring them together

: to get (one or more things) from a place

: to get (similar things) and bring them together as a hobby
 the latter seems as more suitable in characterization of role of MA(s) in
executing Passive Measurement methods.
RE: Measurement Domain. Given earlier discussion and suggestion to take
holistic approach to MA/MP role, I believe we are at the point where
discussion of Measurement Domain's definition and use is timely and
appropriate.

Regards,
Greg

On Wed, Jun 4, 2014 at 8:34 AM, <[email-masked]> wrote:

>> [phil] I don't really understand what difference you're getting at - what
>> meaning do you want to convey with "collect information" that differs from
>> "observes"?
>>
>>
>>  Active Measurement Task: A Measurement Task in which a Measurement
>> Agent sends Active Measurement Traffic to, or receives it from, one or more
>> other Measurement Agents or Measurement Peers, and perhaps coordinates with
>> them using protocols outside the initial LMAP work scope
>>
>   GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And
>> I'd like to discuss new Measurement Domain object defined as:
>>
>   The community of Measurement Agents and Measurement Peers that
>> cooperate in performing a Measurement Task, whether Active or Passive,
>> present a Measurement Domain. Coordination protocol(s) used within
>> Measurement Domain are outside of the initial LMAP work scope.
>>
>  [phil] yes, Active Measurement Traffic is what you could call test
> traffic ["Active Measurement Traffic: the packet(s) generated in order
> to execute an Active Measurement Task."]
>
> [phil] re measurement domain - i can see this may be a useful concept, but
> i don't think we've needed this term yet in lmap. given how tricky agreeing
> terminology is, can we delay defining this term until we're sure we need it.
>
> thanks
> phil
>

---

From: KEN KO <[email-masked]>
Date: Wed, 4 Jun 2014 23:03:14 +0000

As I read this email thread which is similar to earlier ones discussing active vs. passive, I keep thinking about the only place the distinction is being used in the lmap framework, which is for suppression. And, I keep thinking that we are creating a distinction the details of which we cannot agree on, and that different test system operators  intend to use in different ways. And this leads me to think that there is a better way to provide the agreed suppression behavior while allowing test system operators to modify it as they wish.

Default suppression behavior, as specified in framework-05:

“Suppression means that the MA does not begin any new
Active Measurement Task. The impact on other Measurement Tasks is
not defined by LMAP; since they do not involve the MA creating any
Active Measurement Traffic there is no need to suppress them, however
it may be simpler for an implementation to do so.”

We have arrived at this point because stakeholders could not agree on how to treat Passive Tasks. As a result, some operators may suppress Passive Tasks by default and others may let them continue, with variations between those two extremes. And yet, since we are still debating where to draw the line between Active and Passive, the matter is not settled.

There is a better way. Simply add a field – a Boolean true/false flag is all that is required – to the Measurement Task Configuration indicating whether that Task is to be suppressed by default. It shortcuts the Active Passive arguments (at least, in lmap) and gives operators complete freedom over default suppression behavior.

The description of a Measurement Method in a registry could contain a recommended value for the flag. However, operators would be free to use that value or override it in their deployments.

Comments?

Ken

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, June 04, 2014 10:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

Hi Phil,
ob·serve verb \əb-ˈzərv\

col·lect verb \kə-ˈlekt\

: to get (one or more things) from a place
: to get (similar things) and bring them together as a hobby
the latter seems as more suitable in characterization of role of MA(s) in executing Passive Measurement methods.
RE: Measurement Domain. Given earlier discussion and suggestion to take holistic approach to MA/MP role, I believe we are at the point where discussion of Measurement Domain's definition and use is timely and appropriate.
Regards,
Greg

On Wed, Jun 4, 2014 at 8:34 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Proposal:-

thanks
phil

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Jun 2014 09:03:11 +0200

hi Ken, all,

No hats, comments inline...

> The description of a Measurement Method in a registry could contain a recommended value for the flag. However, operators would be free to use that value or override it in their deployments.

This does seem like a good way _not_ to have this discussion here. I tend to agree -- the closer that the LMAP framework can get to treating all Measurement Tasks as black boxes, the properties of which are task-specific, and only those properties which have an effect on control flows are exposed to LMAP.

Having a "suppression default" property is IMO a _much_ better way to separate mechanism and policy than trying to infer or impose these defaults based upon a definition of a class of measurement tasks.

> the latter seems as more suitable in characterization of role of MA(s) in executing Passive Measurement methods.

I tend to disagree -- not with your analysis of common definitions of the terms "observe" and "collect", but with the terms as they have been used in passive measurement architectures in the IETF. Here I refer to RFC 7011, section 2:

   Observation Point

      An Observation Point is a location in the network where packets
      can be observed.  Examples include a line to which a probe is
      attached; a shared medium, such as an Ethernet-based LAN; a single
      port of a router; or a set of interfaces (physical or logical) of
      a router.

   Collecting Process

      A Collecting Process receives IPFIX Messages from one or more
      Exporting Processes.  The Collecting Process might process or
      store Flow Records received within these Messages, but such
      actions are out of scope for this document.

In this case, an MA hosts one or more Observation Points, and therefore observes the traffic. _Collection_ is the act of receiving reports from an MA at... ah, at a Collector (-framework-05 section 3):

   Collector: A function that receives a Report from a Measurement
   Agent.

Cheers,

Brian

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 10:13:21 +0100

i think this is a very good suggestion. i agree this is the right way of separating policy and protocol

as a side benefit, we can then drop the active vs passive distinction (and terminology) (and do some slight rephrasing in the privacy section, which is the main place that uses the terms)

thanks
phil

________________________________
From: KEN KO [[email-masked]]
Sent: 05 June 2014 00:03
To: Greg Mirsky; Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: RE: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

Comments?

Ken

Hi Phil,

Proposal:-

thanks
phil

---

From: "Marc Ibrahim" <[email-masked]>
Date: Thu, 5 Jun 2014 12:48:52 +0300

Hi,

Trevor has already proposed this kind of flag in a previous discussion about suppression. It was proposed to avoid suppressing main control tasks at MA.

I agree that this flag solves the problem of default suppression behavior.

I am just wondering if this flag should be present at the method or task level. 

BR,

Marc.

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 05, 2014 12:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

thanks

phil

  _____  

Comments?

Ken

Hi Phil,

ob·serve verb \əb-ˈzərv\ 

vs.

col·lect verb \kə-ˈlekt\ 

Regards,

Greg

Proposal:-

thanks

phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 11:54:15 +0200

> I am just wondering if this flag should be present at the method or task level. 

I believe LMAP only has tasks (or should only have tasks).

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 5 Jun 2014 12:34:38 +0000

+1
Barbara

From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 05, 2014 5:13 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

thanks
phil

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

Comments?

Ken

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, June 04, 2014 10:40 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

Hi Phil,

Proposal:-

thanks
phil

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 09:11:28 +0100

Just to highlight the proposed changes before I implement them:-

* a "suppression flag"
a Boolean true/false flag is all that is required – to the Measurement Task Configuration indicating whether that Task is to be suppressed by default (in other words, if the Controller sends a suppression message without specifying particular Tasks to be suppressed, then the MA would check the Boolean flag for each Task)

* remove the definition of Active and Passive

please shout if you're unhappy with these changes

thanks
phil

________________________________
From: lmap [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: 05 June 2014 10:13
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

thanks
phil

Comments?

Ken

Hi Phil,

Proposal:-

thanks
phil

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 6 Jun 2014 18:33:07 -0700

Hi Phil,
I'd add Configuration protocol (Section 5.2) to the list of issues to be
addressed based on comments to -05 version.

Regards,
Greg

On Fri, Jun 6, 2014 at 1:11 AM, <[email-masked]> wrote:

> a Boolean true/false flag is all that is required – to the Measurement
> Task Configuration indicating whether that Task is to be suppressed by
> default (in other words, if the Controller sends a suppression message
> without specifying particular Tasks to be suppressed, then the MA would
> check the Boolean flag for each Task)
>
>  ------------------------------
> *From:* lmap [[email-masked]] On Behalf Of [email-masked] [
> [email-masked]]
> *Sent:* 05 June 2014 10:13
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
> as a side benefit, we can then drop the active vs passive distinction
> (and terminology) (and do some slight rephrasing in the privacy section,
> which is the main place that uses the terms)
>
> thanks
> phil
>
>  ------------------------------
> *From:* KEN KO [[email-masked]]
> *Sent:* 05 June 2014 00:03
> *To:* Greg Mirsky; Eardley,PL,Philip,TUB8 R
> *Cc:* [email-masked]
> *Subject:* RE: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
>   As I read this email thread which is similar to earlier ones discussing
> active vs. passive, I keep thinking about the only place the distinction is
> being used in the lmap framework, which is for suppression. And, I keep
> thinking that we are creating a distinction the details of which we cannot
> agree on, and that different test system operators  intend to use in
> different ways. And this leads me to think that there is a better way to
> provide the agreed suppression behavior while allowing test system
> operators to modify it as they wish.
>
>
>
> We have arrived at this point because stakeholders could not agree on how
> to treat Passive Tasks. As a result, some operators may suppress Passive
> Tasks by default and others may let them continue, with variations between
> those two extremes. And yet, since we are still debating where to draw the
> line between Active and Passive, the matter is not settled.
>
>
>
> There is a better way. Simply add a field – a Boolean true/false flag is
> all that is required – to the Measurement Task Configuration indicating
> whether that Task is to be suppressed by default. It shortcuts the Active
> Passive arguments (at least, in lmap) and gives operators complete freedom
> over default suppression behavior.
>
>
>
> The description of a Measurement Method in a registry could contain a
> recommended value for the flag. However, operators would be free to use
> that value or override it in their deployments.
>
>
>
> Comments?
>
>
>
> Ken
>
>
>
>
>
> *From:* lmap [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Wednesday, June 04, 2014 10:40 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
>
>
> Hi Phil,
>
> [phil] yes, Active Measurement Traffic is what you could call test traffic
> ["Active Measurement Traffic: the packet(s) generated in order to execute
> an Active Measurement Task."]
>
>
>