Subject: [lmap] Feedback on draft-eardley-lmap-terminology

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Jul 2013 18:11:31 +0200

Dear authors,

A couple of high level points.
One of the goal behind this email is to generate discussions, either on 
the list, or during the IETF meeting next week.

-

    The consensus is that the LMAP working group should assume that a
    Measurement Agent receives Instruction from only a single Controller
    at any point in time (however it may Report to more than one
    Collector).

Instead of consensus, I would use "a key assumption"
The charter says:

    A key assumption constraining the initial work is that the
    measurement system is under the control of a single organization
    (for example, an Internet Service Provider or a regulator).

-
Same remark for the term "consensus" in

        The job of a Bootstrap Protocol is to provide an automated way to
        associate a Measurement Agent to its Controller, including
        authentication credentials.  Similarly, there should be a way to pull
        the plug on rogue Measurement Agents.  The current consensus on the
        LMAP mailing list is that the working group should define the
        bootstrap process but not a protocol.

The charter mentions:

    "The management protocol to bootstrap the MAs in measurement devices
    is out of scope of the LMAP charter."

-
I would like to draw your attention to claise-ippm-perf-metric-registry 
<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, 
which will be presented in IPPM.

-
I'm not too clear if the Measurement Peer are dedicated test server, or 
real server (google.com, SIP server, youtube)
Do the Measurement Peer need the functionality of an IP SLA responder or 
a TWAMP controller?
This might be clarified in the use case draft.

-
This draft is good shape, but it's really a mix of terminology and 
framework concepts.
I'm glad that there is a single delivery in the charter for both:
"1. The LMAP Framework - provides common terminology, basic architecture 
elements, and justifies the simplifying constraints"

Regards, Benoit

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 09:00:34 +0100

Benoit,

Thanks for your comments!

I agree with you that "key assumption" is more accurate than "consensus"

I agree that Section 4, "Commentary and notes" wanders into the territory of the Framework. At some point soon, as you say, terminology will be merged into a framework i-d, so this will need to be fixed. I'll try to ensure that the merged doc keeps some text that explains the terminology a bit (personally I find terminology on its own hard to understand, without some accompanying explanation)

Ps your registry i-d is now on my reading list, thanks

<< I'm not too clear if the Measurement Peer are dedicated test server, or real server (google.com, SIP server, youtube)>>
The Measurement Peer could be either. It's up to the operator of the measurement system to decide what Measurement Methods the Measurement Peer needs and exactly how they're implemented.

Thanks
phil

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 22 July 2013 17:12
To: [email-masked]
Subject: [lmap] Feedback on draft-eardley-lmap-terminology

Dear authors,

A couple of high level points.
One of the goal behind this email is to generate discussions, either on the list, or during the IETF meeting next week.

-

   Collector).
Instead of consensus, I would use "a key assumption"
The charter says:
A key assumption constraining the initial work is that the measurement system is under the control of a single organization (for example, an Internet Service Provider or a regulator).
-
Same remark for the term "consensus" in

   bootstrap process but not a protocol.
The charter mentions:
"The management protocol to bootstrap the MAs in measurement devices is out of scope of the LMAP charter."
-
I would like to draw your attention to claise-ippm-perf-metric-registry<http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, which will be presented in IPPM.

-
I'm not too clear if the Measurement Peer are dedicated test server, or real server (google.com, SIP server, youtube)
Do the Measurement Peer need the functionality of an IP SLA responder or a TWAMP controller?
This might be clarified in the use case draft.

-
This draft is good shape, but it's really a mix of terminology and framework concepts.
I'm glad that there is a single delivery in the charter for both:
"1. The LMAP Framework - provides common terminology, basic architecture elements, and justifies the simplifying constraints"

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jul 2013 10:31:32 +0200

Phil,
>
> **
>
> *<<*I'm not too clear if the Measurement Peer are dedicated test 
> server, or real server (google.com, SIP server, youtube)>>
>
> *The Measurement Peer could be either. It's up to the operator of the 
> measurement system to decide what Measurement Methods the Measurement 
> Peer needs and exactly how they're implemented.*
>
Sure, but what if I point all my 100.000 MAs to constantly ping 
http://home.bt.com/news-01363796671918. Not sure if BT will be happy.
I could take a different example with DNS, NTP, CDN, ...
That might be a point for an applicability section somewhere.

Regards, Benoit
>
> **
>
> **
>
> Thanks
>
> phil**
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Benoit Claise
> *Sent:* 22 July 2013 17:12
> *To:* [email-masked]
> *Subject:* [lmap] Feedback on draft-eardley-lmap-terminology
>
> Dear authors,
>
> One of the goal behind this email is to generate discussions, either 
> on the list, or during the IETF meeting next week.
>
> -
>
> A key assumption constraining the initial work is that the measurement 
> system is under the control of a single organization (for example, an 
> Internet Service Provider or a regulator).
>
> -
> I'm not too clear if the Measurement Peer are dedicated test server, 
> or real server (google.com, SIP server, youtube)
> "1. The LMAP Framework - provides common terminology, basic 
> architecture elements, and justifies the simplifying constraints"
>
>
> Regards, Benoit
>

---

From: <[email-masked]>
Date: Wed, 24 Jul 2013 12:46:02 +0100

Ok, this should be mentioned in the Use case doc as well as in the framework.

incidentally, although the measurement functionality would be in lots of MAs I wouldn't expect them all to run all the tests at the same time - for the regular tests, I think you'd use a subset as a panel, and over the course of a few weeks say the panel would rotate round the different end hosts

I agree that the measurement functionality has the potential to be abused as a DDOS attack and we need mechanisms to alleviate it.
Perhaps too early for specific proposals, but I'd suggest a combination of:

-       Security on the Control Protocol (to stop rogue controller asking MAs to launch a DDoS)

-       Some individual tests to include an initial phase where they check that the Measurement Peer has capacity (especially for tests that create a significant load on the Measurement Peer)

-       Ability for Controller to send a "suppress" msg - so lots of MAs can be told to stop sending test pkts, if there's some problem

-       Perhaps some guidance on best practice (don't kill bt.com - try cisco.com instead!!)

Thanks
phil

From: Benoit Claise [mailto:[email-masked]]
Sent: 24 July 2013 09:32
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology

Phil,

Sure, but what if I point all my 100.000 MAs to constantly ping http://home.bt.com/news-01363796671918. Not sure if BT will be happy.

Regards, Benoit

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: 22 July 2013 17:12
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] Feedback on draft-eardley-lmap-terminology

Dear authors,

-

   Collector).

-

-

Regards, Benoit

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Wed, 24 Jul 2013 09:04:41 -0400

Hi Phil and Benoit,

Even dedicated test server capacity can be overrun at large scale.

Case in point:
A manufacturer of consumer WLAN access points sold in the US
coded the IP of a single NTP server in every device, and rather
suddenly the US Naval Observatory NTP server they chose
had >10k clients they didn't plan on serving
(I've cc'd Karen O'Donoghue who may clarify or add to this story).
IIRC, this was a case where IETF guidance
(ask permission before adding someone's NTP server to your list,
and use DNS names instead of IP addresses) was ignored.

The two points above apply to LMAP, especially for tests
involving DNS servers, and we can add them to Phil's list below.

Al

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 24, 2013 7:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology

Thanks
phil

Phil,

Regards, Benoit

Thanks
phil

Dear authors,

-

   Collector).

-

-

Regards, Benoit

---

From: Paul Aitken <[email-masked]>
Date: Wed, 24 Jul 2013 14:06:38 +0100

Phil,

I've been reviewing the drafts, and these are all points I planned to raise.

Inline:

> incidentally, although the measurement functionality would be in lots 
> of MAs I wouldn't expect them all to run all the tests at the same 
> time -- for the regular tests, I think you'd use a subset as a panel, 
> and over the course of a few weeks say the panel would rotate round 
> the different end hosts
>

What I read so far seems to focus on the singular test case, whereas in 
reality there may be many MAs performing the same test, even at the same 
time.

> I agree that the measurement functionality has the potential to be 
> abused as a DDOS attack and we need mechanisms to alleviate it.
>

+1. Similar the reporting infra, if 1,000's of MAs are told to send 
reports to www.bt.com.

> -Security on the Control Protocol (to stop rogue controller asking MAs 
> to launch a DDoS)
>

+1.

> -Some individual tests to include an initial phase where they check 
> that the Measurement Peer has capacity (especially for tests that 
> create a significant load on the Measurement Peer)
>

That might not be possible, eg if the test is a DNS lookup or web page 
retrieval, the peer may have no knowledge that it's involved in an LMAP 
measurement.

> -Ability for Controller to send a "suppress" msg -- so lots of MAs can 
> be told to stop sending test pkts, if there's some problem
>

Also to stop sending reports. This needs to be similarly secure so a 
rogue controller can't suppress sections of the LMAP network.

> -Perhaps some guidance on best practice (don't kill bt.com -- try 
> cisco.com instead!!)
>

:-)

P.

> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* 24 July 2013 09:32
> *To:* Eardley,PL,Philip,TUB8 R
> *Cc:* [email-masked]
> *Subject:* Re: [lmap] Feedback on draft-eardley-lmap-terminology
>
> Phil,
>
> **
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *To:* [email-masked] <mailto:[email-masked]>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Jul 2013 13:43:53 +0000

I agree that the draft is in pretty good shape, and that much of the terminology content is ready to be incorporated into the framework draft.

But we have two framework I-Ds at this point in time! This is not a bad thing and individual contributions are welcome at this point. However, we have a tight schedule to consolidate the two in one WG framework draft.

One of the points where the framework is still confusing for me and the terminology I-D does not help is the controller.

Says the terminology I-D:

Controller: A function that provides a Measurement Agent with
   Instruction(s).  Colloquially, a Controller is a physical device that
   performs this function.

Do we really envision physical devices that perform this (only) function?

More unclarity. The single controller (for a given MA) key assumption is not mentioned by draft-akhter-lmap-framework. Why? The other framework draft draft-eardley-lmap-framework doest take into account the key assumtion, but then talks about the MA pulling configuration from the Controller in order to avoid firewall traversal problems. Does this eliminate a-priori the usage of NETCONF as a possible transport for the Control Protocol?

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Monday, July 22, 2013 7:12 PM
To: [email-masked]
Subject: [lmap] Feedback on draft-eardley-lmap-terminology

Dear authors,

-

   Collector).

-

-

Regards, Benoit

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Wed, 24 Jul 2013 09:59:43 -0400

Hi Dan,

you wrote:

Not necessarily.

Jürgen proposed one possible fix for MA connection initiation with NETCONF,
"Call Home for TLS". See slides 6 and 7 of his presentation:
http://www.ietf.org/proceedings/86/slides/slides-86-lmap-3.pdf

IIRC, this proposal was to be discussed elsewhere, and perhaps we can
learn the outcome on LMAP list.

regards,
Al

From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, July 24, 2013 9:44 AM
To: Benoit Claise; [email-masked]
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology

Regards,

Dan

Dear authors,

-

   Collector).

-

-

Regards, Benoit

---

From: Paul Aitken <[email-masked]>
Date: Wed, 24 Jul 2013 16:00:58 +0100

Dan,

> The single controller (for a given MA) key assumption is not mentioned 
> by draft-akhter-lmap-framework. Why?

The only key assumption (in the LMAP WG charter) is "that the 
measurement system is under the control of a single organization".

Given that assumption, we don't see the necessity of restricting an MA 
to a single controller.
This allows for redundant / backup controllers, or a controller cloud 
(thinking of rserpool, eg).

P.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jul 2013 17:12:17 +0200

> Do we really envision physical devices that perform this (only) function?

For me, the second sentence is rather pointless. I see not reason why
a controller may not be a virtual machine. The controller is a
function, it does not really matter how it is realized. Note that we
have similar sentences for the Collector and Measurement Agents (and I
think they all three could go).
 
> More unclarity. The single controller (for a given MA) key assumption is not mentioned by draft-akhter-lmap-framework. Why? The other framework draft draft-eardley-lmap-framework doest take into ac…

Perhaps things need to be rephrased but then I am not sure which
sentence in draft-eardley-lmap-terminology-02 you think is ruling out
NETCONF. The underlying requirement is that sessions need to be
initiated by the MAs since they may be behind NATs or other
middleboxes.

/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, 24 Jul 2013 17:15:07 +0200

> learn the outcome on LMAP list.

The NETCONF WG is working on call home solutions, both for NETCONF over
TLS and NETCONF over SSH. The relevant I-Ds are:

http://tools.ietf.org/wg/netconf/draft-ietf-netconf-reverse-ssh/
http://tools.ietf.org/wg/netconf/draft-ietf-netconf-rfc5539bis/

There are fairly new I-Ds and hence it is too early to declare any
outcomes. The NETCONF WG meets in Session 2013-07-31 1510-1610 and
Session 2013-07-31 1620-1720.

/js

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 24 Jul 2013 21:22:34 +0200

El 24/07/13 17:00, Paul Aitken escribió:
> Dan,
>
>> The single controller (for a given MA) key assumption is not 
>> mentioned by draft-akhter-lmap-framework. Why?
>

Right, i would express that each MA is under one controller at any point 
in time. It can change controller (i.e. backup) but i think having more 
than one controller controlling simoultaneously one MA introduces a lot 
of complexity and i am not sure it is worth it.

MAkes sense?

Regards, marcelo

---

From: Paul Aitken <[email-masked]>
Date: Wed, 24 Jul 2013 21:18:07 +0100

Marcelo,

>> Given that assumption, we don't see the necessity of restricting an 
>> MA to a single controller.
> Right, i would express that each MA is under one controller at any 
> point in time. It can change controller (i.e. backup) but i think 
> having more than one controller controlling simoultaneously one MA 
> introduces a lot of complexity and i am not sure it is worth it.
>
> MAkes sense?

Since the system is under control of a single organization, it's up to 
that organisation how to organise their controllers and MA's. We should 
make it possible for them to do what they want, rather than making it 
possible to only do what we think is best.

MA's should do what they're requested by controllers as best as they're 
able. I can't immediately think of a situation where an MA could be 
given conflicting instructions. However, if conflicts are possible the 
MA could enqueue the requested tests to be run sequentially to avoid 
inter-test conflict. If conflict can arise from two controllers, then it 
can also arise by requesting the same tests from a single controller - 
so designing this limitation into the system gains nothing.

P.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jul 2013 22:49:24 +0200

On Wed, Jul 24, 2013 at 09:18:07PM +0100, Paul Aitken wrote:
 
> MA's should do what they're requested by controllers as best as
> they're able. I can't immediately think of a situation where an MA
> could be given conflicting instructions. However, if conflicts are
> possible the MA could enqueue the requested tests to be run
> sequentially to avoid inter-test conflict. If conflict can arise
> from two controllers, then it can also arise by requesting the same
> tests from a single controller - so designing this limitation into
> the system gains nothing.

C1: do test X
C2: don't do test X

or

C1: do test X every 10 minutes
C2: do test X every 8 minutes

What should the MA do?

/js

---

From: Paul Aitken <[email-masked]>
Date: Wed, 24 Jul 2013 22:07:09 +0100

Juergen,

>> the system gains nothing.

You're supposing inter-controller communication, such that C2 knows that 
C1 requested X ?

The MA should do test X as requested by C1. It should ignore the command 
from C2, because C2 didn't request test X.

It's clearer if the sequence was:

C2: do test X
C1: do test X
C2: don't do test X

Then C2 is cancelling its previous command, whereas C1's command stands.

> C2: do test X every 8 minutes

The MA should do test X multiple times exactly as requested.

If both requests are received at exactly the same instant (which is a 
corner case, even if we're talking about multiple processors + multiple 
interfaces), then every 40 minutes test X could be run just once as an 
optimisation.

More realistically, test X will be run at t0, t10, t20, t30, ... for C1 
and at t1, t9, t17, t25, ... for C2. These times never coincide.

P.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jul 2013 11:16:06 +0200

On Wed, Jul 24, 2013 at 10:07:09PM +0100, Paul Aitken wrote:

[...]

You I think you are proposing that instructions received from
different Controllers must be kept separate and the MA must act
towards a Controller as if there are no other controllers. A potential
problem with this is that there are likely instructions and tests that
do impact each other through side effects.  

   If C1 schedules a test to be started every 5 min past the hour that
   requires no cross traffic while C2 schedules a test to measure
   video streaming capabilities during the interval 3-7 minutes past
   the hour, then C1 will be surprised that the scheduled test never
   executes or produces wrong results.

Do you require that the MA has the logic to reject one of the
instructions in such a case? Or do you expect that the Controllers
will simply accept that MAs may not do what they think they should be
doing? Or do you expect to have at least read access to all
instructions? Will we end up with an access control model to handle
things properly in a configurable manner (like we did with SNMP and
NETCONF)?

If the assumption is complete separation then I believe this is quite
a big one - in particular if I consider devices like home routers or
hardware probes of some bigger existing measurement platforms as
potential targets for this work (usuall small embedded Linux systems
running on cheap hardware).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jul 2013 09:17:22 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > More unclarity. The single controller (for a given MA) key assumption
> is not mentioned by draft-akhter-lmap-framework. Why? The other
> framework draft draft-eardley-lmap-framework doest take into account the
> key assumtion, but then talks about the MA pulling configuration from
> the Controller in order to avoid firewall traversal problems. Does this
> eliminate a-priori the usage of NETCONF as a possible transport for the
> Control Protocol?
> >
> 
> initiated by the MAs since they may be behind NATs or other middleboxes.
> 

[[DR]] The phrase I am refering to is not from draft-eardley-lmap-terminology-02 but from draft-eardley-lmap-framework-02, section 2. In my reading this sentence does not talk about who initiates the session, but about the way the configuration itself is to reach the MAs: 

>  To avoid problems with NAT and firewalls, it is likely that the MA
   'pulls' the configuration from its Controller, as identified by the
   Initialiser.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jul 2013 09:24:04 +0000

Sorry, draft-eardley-lmap-framework-02, section 3.2

> From: Romascanu, Dan (Dan)
> Sent: Thursday, July 25, 2013 12:17 PM
> To: 'Juergen Schoenwaelder'
> Cc: Benoit Claise; [email-masked]
> Subject: RE: [lmap] Feedback on draft-eardley-lmap-terminology
> 
> 
> 
> 
> 
> > framework draft draft-eardley-lmap-framework doest take into account
> > the key assumtion, but then talks about the MA pulling configuration
> > from the Controller in order to avoid firewall traversal problems.
> > Does this eliminate a-priori the usage of NETCONF as a possible
> > transport for the Control Protocol?
> > >
> >
> [[DR]] The phrase I am refering to is not from draft-eardley-lmap-
> terminology-02 but from draft-eardley-lmap-framework-02, section 2. In
> my reading this sentence does not talk about who initiates the session,
> but about the way the configuration itself is to reach the MAs:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jul 2013 11:45:28 +0200

>    'pulls' the configuration from its Controller, as identified by the

OK. I guess this should then be reworded to read like this (or
something similar):

  To avoid problems with NAT and firewalls, it is likely that the MA
  is required to establish the transport layer connection over which
  it receives its configuration from its Controller, as identified by
  the Initialiser.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jul 2013 09:46:46 +0000

> university.de]
> Sent: Thursday, July 25, 2013 12:45 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> OK. I guess this should then be reworded to read like this (or something
> similar):
> 

[[DR]] yes - this makes sense. 

Dan

---

From: <[email-masked]>
Date: Thu, 25 Jul 2013 14:27:35 +0100

Dan, Juergen - Thanks, good catch and the re-phrasing seems good to me.

Also Dan said
<< But then in the diagram in Figure 1 the arrow points from the Controller to the MA, and later the examples of possible protocols in Section 5.3 include such 'push' protocols as SNMP and NETCONF>>

I'll clarify that the arrow is about the Instruction. The control protocol may need some back and forth (to request or 'pull' the Instruction)

> Sent: 25 July 2013 10:47
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> > my reading this sentence does not talk about who initiates the
> > session, but about the way the configuration itself is to reach the
> MAs:
> > >
> > something

---

From: Paul Aitken <[email-masked]>
Date: Thu, 25 Jul 2013 14:40:28 +0100

Juergen,

> towards a Controller as if there are no other controllers.

To some extent, yes.

> A potential

Forget about multiple controllers: this situation could arise from a 
single controller.

So a rejection mechanism will surely be necessary regardless of whether 
there are one or multiple controllers:
     - whether the command protocol is two-way, so the command is 
immediately rejected.
     - or, the report protocol includes a way of reporting that the 
requested test could not be done.
     - or both.

> instructions in such a case?

Definitely, even for the single controller case.

> Or do you expect that the Controllers
> doing?

Ideally the MA would report that a) it cannot perform the requested 
test, and b) why that is so.
Revealing too much information in (b) is usually a security risk. 
However it's not an issue in this case since we're assuming that the 
system is under control of a single organisation.

> Or do you expect to have at least read access to all

No, not at all.

> running on cheap hardware).

If an MA may be commanded to perform multiple tests¹ by a single 
controller, then the potential conflicts are the same as multiple tests 
from multiple controllers.

¹ This is necessary if we are to build complex tests out of simpler test 
primitives, eg DNS lookup followed by file download.

P.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Jul 2013 20:20:07 +0200

On Thu, Jul 25, 2013 at 02:40:28PM +0100, Paul Aitken wrote:
> So a rejection mechanism will surely be necessary regardless of
> whether there are one or multiple controllers:

[...]

> controller, then the potential conflicts are the same as multiple
> tests from multiple controllers.
> 
> ¹ This is necessary if we are to build complex tests out of simpler
> test primitives, eg DNS lookup followed by file download.

Yes, but in this case, it is a single active controller making a
mistake and thus this is likely easier to debug and deal with compared
to multiple controllers 'fighting' over the resources of a MA. If we
design for multiple active controllers, we need to build the necessary
coordination primitives right into the MA for version 1.0, something I
would prefer to avoid since I have the feeling that this adds
complexity and will likely delay things.

/js