Index: script.txt
==================================================================
--- script.txt
+++ script.txt
@@ -28,10 +28,11 @@
   researchers to experiment on real community networks. *##*
 
 ** Testbed?
 - Environment built with real hardware for realistic experimental research on
   network technologies. *##*
+# Axel: Insert headline "Examples of existing testbeds".
 - Some wireless testbeds, both indoor and outdoor.
   - Problems: their limited local scale, their unrealistic controlled
     environment, experiments can't share resources simultaneously.
 - Internet: PlanetLab, planet-scale testbed with resource sharing on nodes.
   Main inspiration for Community-Lab. *##*
@@ -41,10 +42,11 @@
 - Integrates and extends the participating community networks.
 - Using the FEDERICA research backbone for interconnection. *##*
 - All Community-Lab's software and documentation is “free as in freedom” so
   people can use it to setup their own CONFINE testbed.
 
+# Axel: Headline: for what?
 * Requirements and challenges
 A testbed has requirements that are challenged by the unique characteristics
 of CNs.  For instance, how to *##*
 
 ** Simple management vs. Distributed node ownership
@@ -84,10 +86,12 @@
 * Community-Lab testbed architecture
 ** Overall architecture
 This is the architecture developed by the CONFINE project to handle the
 previous challenges.  It applies to all testbeds using CONFINE software. *##*
 
+# Axel: Introduce scenario: CNs, nodes, admins.
+# Ivan: Don't zoom.
 - A testbed consists of a set of nodes managed by the same server. *##*
   - Server managed by testbed admins.
   - Network and nodes managed by CN members.
   - Node admins must adhere to testbed terms and conditions.
   - This decouples testbed management from infrastructure ownership & mgmt. *##*
@@ -101,17 +105,20 @@
   - They can also route the management network to the Internet. *##*
 - Researchers run experiments in slices spread over several nodes (as
   slivers). *##*
 
 ** Slices, slivers and nodes
+# Axel: Reverse, from PoV of researcher: select nodes, run as slivers, gruop in slices.
 - These concepts are inspired in PlanetLab.
 - A slice is a management concept that groups a set of related slivers.
 - A sliver holds the resources (CPU, memory, disk, bandwidth, interfaces…)
   allocated for a slice in a given node.
 - A node hosts several slivers at the same time. *##*
 
 ** Node architecture
+# Axel: More stress on node itself.
+# Ivan: Don't zoom!!
 allows the realization of these concepts.  *##* A node consists of a CD, a RD
 and a rD connected to the same wired local network. *##*
 
 - The community device
   - Completely normal CN device, so existing ones can be used.
@@ -133,10 +140,11 @@
       stability, isolation and privacy (partialy implemented). *##*
 - The recovery device (not implemented) can force a remote hardware reboot of
   the RD in case it hangs.  It also helps with upgrade and recovery. *##*
 
 * Experiments support
+# Axel: Turn around as of mail: from PoV of researcher: 1) testbed through API, choose nodes, 2) login OoB, 3) auto creation, 4) specific interfaces.
 Researchers can configure slivers with different types of network interfaces
 depending on the connectivity needs of experiments.  For instance, to *##*
 
 - mimic a home PC: use the private interface, *##* which has L3 traffic
   forwarded using NAT to the CN but filtered to ensure network stability. *##*
@@ -168,10 +176,11 @@
 
 ** An example experiment
 to show how the testbed works.  We'll create two slivers which ping each
 other. *##*
 
+# Use summary diagram, maybe colorise labels.
 1. The researcher first contacts the server and registers a slice description
    which specifies a template for slivers (e.g. Debian Squeeze) and includes
    data and programs to setup slivers and run experiments. *##*
 2. This and all subsequent changes performed by the researcher are stored in
    the registry, which holds the config of all components in the testbed. *##*
@@ -195,10 +204,11 @@
 
 * Cooperation between community networks and Community-Lab
 can take different forms.  Given a typical CN like this, with most nodes
 linked using cheap and ubiquitous WiFi technology: *##*
 
+# Axel: Keep CN on sight, explain RDs and RD links (DIs) in cloud.
 - CN members can provide an existing CD and let CONFINE connect a RD to it via
   Ethernet.  Experiments are restricted to the application layer unless the
   node owner allows the RD to include a direct interface (i.e. antenna). *##*
 - CN members can provide a location and let CONFINE set up a complete node
   there (CD and RD).  In this way CONFINE helps extend the CN. *##*