![](media/image1.wmf)

ILC-doc-305-v4

June 30, 2006

Version 1

**Evaluation of Electronic Logbooks for Use at**

**FNAL ILC Test Areas**

Suzanne Gysin, Rob Kutschke

Fermilab, Computing Division

Elvin Harms, Wally Kissel, Jim Patrick

Fermilab, Accelerator Division

Mike Tartaglia

Fermilab, Technical Division

Claude Saunders

Argonne National Lab,

Janice Nelson

Stanford Linear Accelerator Center

***Abstract***

The committee recommends that the Control Room Logbook (CRL) be used as
the electronic logbook at the ILC test areas at Fermilab. The CRL has
many of the desired features and there is a clear path to developing
those features that are missing. We also recommend that the users and
the developers of the CRL work together to ensure that the CRL is
updated and deployed in a fashion that best suits the needs of the
project.

**Table of Contents**

[1 Preliminary Comments 2](#preliminary-comments)

[1 Preliminary Comments 2](#__RefHeading___Toc139447809)

[1.1 Logbook vs Notebook 3](#logbook-vs-notebook)

[2 Evolution of the Charge 3](#evolution-of-the-charge)

[2.1 The Original Charge 3](#the-original-charge)

[2.2 Clarifications to the Charge 3](#clarifications-to-the-charge)

[3 Candidate Logbooks 4](#candidate-logbooks)

[4 Some Philosophy and Boundary Conditions
5](#some-philosophy-and-boundary-conditions)

[4.1 What an Elog is Not 5](#what-an-elog-is-not)

[4.2 About Databases 5](#about-databases)

[4.3 A Single View of Many Labs 5](#a-single-view-of-many-labs)

[4.4 A Tradeoff: Ease of Entry vs Robustness of Data
6](#a-tradeoff-ease-of-entry-vs-robustness-of-data)

[5 Methodology 7](#methodology)

[5.1 Threshold for Candidates from Outside of FNAL
7](#threshold-for-candidates-from-outside-of-fnal)

[5.2 Required features 8](#required-features)

[6 Discussion of the Candidates 8](#discussion-of-the-candidates)

[6.1 KBook ( HepBook) 8](#kbook-hepbook)

[6.2 PSI Elog 8](#psi-elog)

[6.3 SNS Elog 9](#sns-elog)

[6.4 JLAB Elog ( as deployed at SLAC) 9](#jlab-elog-as-deployed-at-slac)

[6.5 DESY-IHEP 9](#desy-ihep)

[6.6 DESY TTF elog 10](#desy-ttf-elog)

[6.7 FNAL AD Elog 11](#fnal-ad-elog)

[6.8 TD Weblog 11](#td-weblog)

[6.9 Control Room Logbook 12](#control-room-logbook)

[7 Recommendation 12](#recommendation)

[7.1 Levels of Support 13](#levels-of-support)

[A. What About Hosting the Elog from DESY?
14](#what-about-hosting-the-elog-from-desy)

[B. Change Log 15](#change-log)

# Preliminary Comments

All of the materials examined by the committee, or generated by the
committee are linked from the [Logbook Evaluation
website](../%20http://cd-amr.fnal.gov/ilc/LogbookEvaluation/LogbookEvaluation.htm).
That page contains links to the agenda of meetings, the minutes of
meetings, background material about the products being evaluated and a
link to all [entries with the keyword \'elog\' in the ILC demo Document
Database](https://docdb.fnal.gov/ILC-public/DocDB/Search?keywordsearchmode=anysub&keywordsearch=elog).

## Logbook vs Notebook

In this report we use the terms *logbook* and *notebook,* which are
distinguished as follows. In a logbook, entries may not be edited or
deleted but they may be annotated; a possible exception exists in that
an administrator may edit/remove a broken or grossly misleading entry
for which annotation is an insufficient cure. In a notebook, entries are
designed to be edited and one normally sees the most recent version
first; previous versions are preserved as an audit trail. The classic
use case for a notebook is to manage the iterations of a particular data
analysis.

Another distinction between the two is that logbooks usually allow one
to view information on a shift by shift basis while the concept of a
shift has no meaning for a notebook. For a small, short term project,
one might get away with using the annotation features of a logbook to
emulate a notebook but this is not a reasonable solution for a long term
or large scale project.

# Evolution of the Charge

## The Original Charge

The charge was delivered to the committee from Shekhar Mishra and
Margaret Votava:

Deliver a report to FNAL ILC management by July 1st, 2006 that contains
a recommendation and defense thereof for an electronic logbook to be
used by ILC test areas at A0, Meson, IB1, and New Muon. The committee is
charged with choosing a single recommendation to meet the needs of a
control room logbook AND a single recommendation to meet the needs of an
electronic notebook. The committee is strongly urged to choose the
recommendation(s) from an existing implementation and highly encouraged
to have the same recommendation for both the control room logbook and
the notebook.

##  Clarifications to the Charge

After our initial survey of available products, we discovered many
products billed as logbooks but only one that billed itself as a
notebook. The committee did not believe that it was appropriate to force
the role of a notebook on any of the logbook candidates. Nor did it
believe that the notebook candidate was appropriate; this is discussed
further in the Section 6.1. At this time Margaret and Shekhar instructed
the committee to no longer consider notebooks.

Shekhar and Margaret also advised us that:

1.  We can expect ILC R&D to continue at Fermilab for many years.
    Therefore the logbook we choose should still be usable, say, 10
    years from now. And one should be able to comfortably search over
    the full 10 years of accumulated entries. When the project has
    reached its full scale it may include a few tens of test stands.

2.  The work on ILC cavities will take place at Fermilab, Cornell, JLAB
    and, perhaps later, at SNS. It is very desirable that one be able to
    look at cavity work at all of these locations from single entry
    point. That is, one must be able to ask questions like "show me all
    entries made at all locations since the start of the day shift
    today" or "show me all entries for a particular cavity, regardless
    of the facility at which the entry was made".

3.  The first test area at Fermilab needs to have an electronic logbook
    in place by August 1, 2006 so that it can begin work on components
    that will arrive in early August. While the solution to points 1)
    and 2) may not be available at that time, the committee should
    recommend a logbook whose data can later be migrated to the more
    modern product.

4.  Logbook entries must be unchangeable and this must be enforced by
    the software, not just by convention of use.

# Candidate Logbooks

The logbooks that were investigated are:

1.  **The Control Room Logbook (CRL):** developed by FNAL CD. Used for
    about 5 years. Now used by D0, DES, MINOS, MiniBoone, and the CMS
    forward pixel test beam.

2.  **Technical Division Weblog (TD Weblog):** developed about a year
    ago and is used within technical division.

3.  **Accelerator Division Elog ( AD ELog):** Aka MCR logbook. This
    product has a very strong user base and has been around for a long
    time.

4.  **JLAB logbook as ported to SLAC (JLAB):** This elog has been
    deployed at SLAC for about 2.5 year and sounds very good.

5.  **DESY TTF elog:** This has been the workhorse elog at DESY for
    about 5 years. It has about 15 logbooks, the largest with more than
    80,000 entries.

6.  **DESY IHEP elog:** An evolution of the TTF elog, using a similar
    front end but a different back end. About 3 years experience but
    with fewer users.

7.  **SNS elog:** Main logbook at SNS for about 4 years.

8.  **PSI logbook:** This product was used at MINOS for a while but its
    use is declining due to support problems. It has been choosen by CMS
    for use at the MTCC.

9.  **KBook (previously known as HepBook):** This is the one notebook
    that was considered. KBook is short for KnowledgeBook.

More complete information about each of these logbooks can be found on
the [Logbook Evaluation
website](../%20http://cd-amr.fnal.gov/ilc/LogbookEvaluation/LogbookEvaluation.htm);
in particular there are spreadsheets that compare the architecture
([ILC-doc-292](http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=292))
and user features
([ILC-doc-283](http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=283))
of each product.

A summary of the deciding points for each candidate is given in Section
6.

# Some Philosophy and Boundary Conditions

## What an Elog is Not

1.  A database to hold the main body of test data from cavities under
    test.

2.  A data catalog with a highly granular picture of where to find the
    main body of the test data.

3.  A document management system.

4.  A slow controls data repository.

5.  A system to manage travelers used in the construction of a device.

6.  An analysis notebook.

In a small project that lasts a short time one can probably get away
with using an elog to fulfill all of the above roles. However a large
project with a long time scale will collapse if the above functions are
crammed into an elog. In particular items 1 through 4 above presume some
sort of programmatic data extraction, which is not normally available in
an elog.

Having said this, it is possible that a project that starts small might
use an elog for some of these roles early on. If this choice is made be
sure that the other systems are in place before the project becomes too
large.

## About Databases

Fermilab's site license agreement with Oracle allows us to add another
Oracle instance at minimal cost. Also the base plan for the ILC presumes
a project wide Oracle license. Therefore there is no bias against
Oracle, in favour of less expensive databases.

## A Single View of Many Labs

Point 2) of section 2.2 asks for a solution that allows one to view
logbooks at many labs with a single query. There are at least two
classes of solution to this problem. In one class, a single instance of
the logbook, located at one site, supports entries from multiple
locations and may be browsed from multiple locations. In the second
class, a fancy browser is aware of logbook instances at multiple sites
and is able to make these separate instances appear to the user as a
single entity. This fancy browser is usually referred to as a portal. A
portal-based solution would be very complicated and is far beyond the
resources that are likely to available.

If a few conditions can be met, the first of the two solutions can be
implemented with present technologies. The conditions are:

1.  Sufficient and sufficiently available network bandwidth among sites.

2.  High availability of the logbook server at the host site.

3.  Fast, 24/7 response by the host site to problems reported by the
    remote sites.

4.  Willingness on the part of developers at the the host site to work
    wiith developers at the recmote sites and to incorporate
    improvements to the logbook that are developed at the remote site.

The last two conditions are more political than technical but they are
likely to be the controlling issues. A corollary to the above is that
the chosen elog must support authentication and authorization for users
outside the host lab's firewall. While many products already support
this, few use modern, secure technologies. We should presume that DOE
may someday mandate a secure authentication protocol, such as PKI (Pulic
Key Infrastructure) certificates. Therefore the product chosen should
have a clear upgrade path to use PKI.

## A Tradeoff: Ease of Entry vs Robustness of Data

It is important that data entry be easy, even intuitive, or else the
users will simply not make the necessary entries. This is sometimes used
as an argument against having to "log in" and in favour of a model in
which a common elog window remains open at all times and users simply
sign their entries with their initials, nickname or whatever. One might
even argue that at remote locations one person can log in and then
others can sign the entries made in a common window.

This approach, however, compromises data integrity. If someone mistypes
their name, then a search for entries made by that person will no longer
find the entry in question. This is not a serious issue in the present
use of the AD elog within accelerator operations since few users search
back more than a few shifts, in which case it is possible to read every
entry in order to find the one of interest. It is, however, a very
serious issue if one wishes to search robustly through 10 years of
accumulated entries.

> A similar issue arises when the ID of some cavity or magnet must be
> entered into an entry. If one is writing, for example, about quad Q101
> then it is easy just to type the name. There will, however, be typos
> which results in lost entries that are not found by a search. So the
> committee prefers that the user select the ID of the magnet or cavity
> from a list of known assets. A robust design of this interface is
> important or else the user can accidentally select the wrong asset,
> which reintroduces the original problem.
>
> A related issue is the display of meta-data. Typically the meta-data
> will be displayed in a structured format, above or below the entry
> text. This can distract from the look and feel of the page. One
> frequently hears praises for the AD elog for its absence of such
> clutter; however this clarity comes at the price of less robust
> searching.
>
> The committee prefers that users log in and that the author's name
> field be taken from the login ID. The committee also prefers that
> asset IDs be chosen from some form or menu, even though it may take a
> few iterations to develop a robust style for these menus. The
> developers should also anticipate that the number of assets may become
> large, perhaps in the hundreds or even the small thousands and the
> form or menu interface should scale to accommodate this number.

# Methodology

Initially the committee considered using a use-case driven, bottoms up
approach to derive requirements for the desired system and then to
evaluate the existing products against this set of requirements. After
some discussion we decided against this approach on the grounds that it
would generate an enormous amount of work just to rediscover features
that every candidate already has. We looked for a simpler process to
eliminate candidates.

The committee constructed two questionnaires, one covering the
architecture of the product and the other covering the user features of
a product. Members of the committee contacted the authors of these
products and completed the questionnaires. As expected, a review of the
questionnaires reduced the pool greatly.

Summaries of the architecture questionnaire responses are given in
[ILC-doc-292](http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=292)
and summaries of the user features questionnaire responses are given in
[ILC-doc-283](http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=283).
A summary of the deciding points for each candidate are given in Section
6.

## Threshold for Candidates from Outside of FNAL

The committee is ready to support a product from outside Fermilab if
that product is clearly much superior to all Fermilab products. In the
event, however, that an outside product is only marginally better than
the best Fermilab product, the committee will recommend the best
Fermilab product on the grounds that the new product would simply become
a 4^th^ logbook and the lab's resources are better spent supporting the
logbooks we already have.

## Required features

1.  The normal spectrum of logbook features. This is satisfied by most
    products.

    a.  Make entries by hand using a GUI.

    b.  Annotate entries.

    c.  Make programmatic entries.

    d.  Be able to attach files.

    e.  Inline display of some graphics formats.

    f.  Must be able to view entries by shift.

    g.  Be able to search entries.

    h.  Link from one entry to another.

2.  An architecture which is likely to survive for 10 years and which
    provides a robust environment for future maintenance and
    development.

3.  Authentication of individual users at login time and a growth path
    to modern, secure authentication. This feature is missing from most
    of the candidates.

4.  Source code must be available.

5.  It must be possible to use the elog with only a garden variety web
    browser and no additional software on the client side (with the
    exception that some attachments may not be viewable without
    additional software).

6.  Software must enforce the rule that entries may not be edited.
    Convention itself is not sufficient.

7.  Complex searches involving both meta-data and entry text.

# Discussion of the Candidates

## KBook ( HepBook)

This product is designed as a notebook, not a logbook. The current
version is being used by Shuichi Kunori for CMS. During the
demonstration the product displayed a number of glitches, showing that
it is not yet a production quality product. In addition Fermilab might
only have access to a subset of the source code. Finally, Fermilab would
have to pay commercial software consulting rates for any changes or
improvements that we need.

The committee does not recommend KBook.

## PSI Elog

This product has been tried out at MINOS for use primarily as an
analysis notebook. The users were initially enthusiastic but the system
has been plagued by frequent server crashes that result in the loss of
data not yet committed. Despite significant effort, the collaboration
has not managed to find and fix the underlying problem, in part because
the product has an old architecture and it is delivered as a single file
containing 50,000 lines of c code.

The committee does not recommend the PSI elog.

## SNS Elog

### Pro

This is a very interesting product that has some of the features, such
as certificate based access, that we will need to develop in the product
we choose. The software has been deployed for 4 years and is very
stable. More interesting features are promised in an upcoming release.

### Con

The one major drawback is that the SNS logbook uses a proprietary Apple
database product, WebObjects, which requires a run time license. The
source to WebObjects is not available. If we were to choose this product
there would be a significant lead time to develop in-house expertise to
perform the necessary customizations. There is also some danger of
relying on the long term availability of WebObjects

The committee does not recommend the SNS elog.

## JLAB Elog (as deployed at SLAC)

### Pro

The JLAB Elog has been deployed at SLAC for 2.5 years and at JLAB for an
unknown time before that. The reports from SLAC are that the product is
well liked and that it has all of the required user features. The
product is unique in that it does support drag and drop for adding
images to the elog, but only for its tcl/tk interface, not for its web
browser interface. It also supports the concept of event time as
distinct from entry time.

### Con

As best we can tell, the JLAB Elog is in the same league as the best of
the Fermilab products; it is not a significantly better product. Using
the criteria discussed in Section 5.1, therefore, the committee does not
recommend the JLAB elog.

## DESY-IHEP

### Pro

All buttons, prompt text, tooltips etc are allowed to have multiple
languages; at present English, German and Chinese are implemented. This
logbook is able to search both itself and other logbooks at the same
time; for example it can search within itself and the TTF logbook. Its
own internal searches are indexed and, therefore, fast. It also has a
syntax for cross-referencing to other databases, such as the DESY asset
database.

### Con

Entries are editable and deleteable; an audit trail of edits is not
kept. The author must sign the entries rather than the logbook
identifying the author via the authentication process. While there is an
interesting interface to the DESY asset database, the entry of asset
names is free text, not assisted by menus or forms. The implementation
is 100% servelet based, which the committee feels makes it more
difficult to maintain than other candidates.

The committee does not recommend the DESY-IHEP Elog.

## DESY TTF elog

### Pro

This logbook has an interesting modern architecture and a proven track
record at DESY. Attachments are searchable. The entry text is indexed
for fast searching. There is a nice system for flagging each entry with
an icon to indicate priority/severity. Users can log in from outside the
DESY firewall, using a username and password. There might be useful
synergies from choosing a DESY product for the ILC test areas at
Fermilab.

As with the DESY IHEP elog, entries may be edited or deleted. Unlike
that elog, an audit trail is kept of edited entries and deleted entries
are not really deleted, just marked invisible. The committee accepts
this as passing the requirement that entries be permanent.

The TTF logbook has been used by users at CERN who made their entries
into a logbook hosted at DESY. Kay Rehlich, the developer of the TTF
elog, offered to support our use of TTF in this mode. This is discussed
more in Appendix A but the committee does not recommend this use of the
product.

### Con

Users must sign each entry by hand. There is no traditional annotate
feature, which is replaced by editing of entries. The developers
recommend wiki-style markup conventions that users may choose to follow
to distinguish the hierarchy of annotations from the original text and
from each other. The annotator must sign and date each annotation by
hand.

Each entry is limited to, at most, one attached inline figure.
Inspection of logbooks used at Fermilab and SLAC shows that users
frequently attach multiple images in one entry and comment on them
collectively.

The committee does not recommend this product; while it has many
features it fails the test discussed in Section 5.1

## FNAL AD Elog

### Pro

This elog has a strong user base and people love the ease of making an
entry and the display of entries. Lots of people like the graph paper
background. It is possible to make entries from outside the lab by
logging in with a username/password. One particularly nice feature is
the mouse-over to display thumbnails. The development team is willing to
work to add the features that this product is missing.

### Con

In this elog, all entries must be signed by hand, even if the user has
logged in remotely with a username/password. The search facility is
limited: the only supported search is for all entries in a given time
range that contain a given string. There is, for example, no interface
to restrict searches to just the author name field. Nor can one search
for "string1 and/or string2". There is no facility for selecting asset
names from an approved list. The granularity of the stored information
is poor; for example, the author name is merged into the entry text,
which means that an author search would require parsing the html.

The committee does not recommend using the AD Elog. The committee
acknowledges that the AD Elog was designed for a different mission than
that under consideration here. The authors of the AD Elog have done a
great job in achieving that mission and it is no slight on their efforts
that their product has not been chosen.

## TD Weblog

### Pro

This elog has many of the desired features and it appears to be
straightforward to add the missing features. The author name, device
under test and test stand are selected from menus. The granularity of
the data and meta-data is good; it should be straightforward to migrate
the information to another system should that prove necessary. The
calendar widget is a nice way to select which day to look at.

### Con

The product is relatively new and has a relatively small user base. The
entry text is not indexed, which is needed for a quick word search.
Attachments are not searched.

The committee believes that this product is above threshold but that the
CRL is the better product. This is discussed in more detail in Section
7. The committee is impressed by the high quality of this product that
was developed in such as short time.

## Control Room Logbook

### Pro

The CRL is a mature product that has been deployed about 5 years and has
a large user base. Authors must be authenticated in order to make an
entry. The entry is signed by the system because it knows who the author
is. Assets can be identified using pull down menus, a part of the forms
system. The system can be configured to be shift oriented, including
overlapping shifts, or it can be configured with other time quanta. The
granularity of the metadata is good, and it should be straightforward to
migrate the entries to another system should that prove necessary.

The computing division currently provides 24/7 support for servers that
host the CRL for several experiments. The ILC project could negotiate
space on these servers.

### Con

The entry text is not indexed, which is needed for a quick word search.
The login is not fully secure. Attachments are not searchable.

We have heard many complaints about the user interface, such as font
size and background color. This is the first time that the CRL
development team has heard these complaints and most can be resolved
trivially; the developers are willing to work with the user community to
fix the remaining problems. Other users object to logging in but the
committee believes that logging in is preferred to signing each entry by
hand.

The committee recommends the CRL. See the next section for more details.

# Recommendation

The two products above threshold are the TD Weblog and the CRL. Neither
product has all of the features that will ultimately be required: both
need a more modern authentication and authorization, possibly
certificate based; as the size of the data grows it will become
important to index the entry text to improve search speed; and
attachments can and should be searched.

It is clear that, whichever product is chosen, upgrades and other
support will be required. As the committee believes that it is wasteful
to upgrade and support both products, we choose one, the CRL.

There are several points in favour of choosing the CRL over the TD
Weblog. First, the CRL has the larger user base so it will be easier to
transition the smaller number of Weblog users than vice versa; moreover,
that larger user base will benefit more from the upgrades made to the
CRL. Second, the CRL is a more mature product. Third, the CRL forms
mechanism is more powerful than the Weblog menu system for identifying
the asset for which the entry is being created; the CRL solution will
grow more smoothly as the types and numbers of devices under test
increases. Finally CD currently supports CRL servers 24/7 for several
projects in the lab; the ILC project can negotiate with CD for similar
support.

Therefore the committee recommends that the project choose the CRL as
the electronic logbook for use at the ILC Test Areas.

The committee also points out that, if other labs can be convinced to
use the CRL hosted at Fermilab, then it is possible today to have a
single view of all of the work being done on ILC test stands.

## Levels of Support

The committee recommends that the following upgrades be made to the CRL:

-   Major features:

    -   Security (PKI/Kerberos/SSL).

    -   Indexing of entry text for word searching (Lucene).

    -   Quicker and easier deployment.

    -   Allow images in annotations.

-   Minor features:

    -   Background color and font size options.

    -   Support thumbnails from more image formats (TIFF).

    -   Allow attached images for entries created via the automated
        entry mechanism, the Process Logger.

Suzanne Gysin estimates the effort required to make these upgrades to
the CRL at about 0.5 FTE of a high-end programmer and 0.4 FTE/year for
ongoing support. The committee believes that this effort should include
contributions from all of the divisions that will benefit from the
upgrade of the CRL and we encourage the division and department heads to
allocate the people to do this work.

The present practice among CRL users is that each project appoints their
own administrator who looks after functions such as adding accounts,
maintaining forms and similar routine matters. These administrators are
initially trained by the CRL developers. The committee recommends that
this practice continue for the ILC project's use of the CRL.

A product with the flexibility and power of the CRL can solve a given
problem in many ways. For example, should two test areas be implemented
as separate logbooks or as two categories in one logbook? The committee
reminds the users and developers that they will need ongoing discussions
to make these choices wisely.

# What About Hosting the Elog from DESY? {#what-about-hosting-the-elog-from-desy .Closing}

Kay Rehlich, the developer of the TTF elog offered to create instances
of the TTF elog for the FNAL ILC efforts, hosted from a server at DESY.
While the committee does not recommend this approach, we feel that we
should present our thoughts on the matter.

One obvious attraction of this solution is that, if everything works as
advertised, then this is the path that requires the least time and
effort from Fermilab staff. On the other hand if Fermilab still needs to
upgrade the CRL then there is no benefit to Fermilab, only the potential
downside that the use of the TTF remotely may require more support than
anticipated.

A second attraction is that this choice might help to blaze the trail
towards the goal of having a single view of many labs by having them all
use the same central logbook server; for example it might be easier to
get buy in from other labs if Fermilab has successfully used an offsite
server. In fact, the only really good reason to choose this approach now
is if blazing the trail is a high short- term priority. As noted in
Section 6, the committee preferred the user features of the TD Weblog
and the CRL over those of the TTF elog. It would be better to experiment
with remote servers using one of the preferred elogs.

We do not know if DESY management would permit their staff to give us
the level of support that we need. Before embarking on this solution we
would need to have management at Fermilab and DESY agree on a level of
support that works for both parties. There are many issues here:
response time of DESY staff; access of Fermi programmers to the source
code so that we can make customizations that are too low priority for
DESY; willingness of DESY to deploy our customizations on their site;
willingness of DESY to support elogs from Fermi for projects not related
to the ILC? Is the network availability and bandwidth sufficient?

# Change Log {#change-log .Closing}

+--------+----------+-------------------------------------------------+
| **Ver  | **Issue  | **Description Of Change**                       |
| sion** | Date**   |                                                 |
+--------+----------+-------------------------------------------------+
| 1      |          | Initial Revision                                |
+--------+----------+-------------------------------------------------+
| 2      |          | Comments from Suzanne. Appendix A added. Lots   |
|        |          | of                                              |
|        |          |                                                 |
|        |          | new text in the sections 6.6 and 7.             |
+--------+----------+-------------------------------------------------+
| 3      |          | Next round of comments from Suzanne.            |
+--------+----------+-------------------------------------------------+
| 4      |          | Final version, with comments from all.          |
+--------+----------+-------------------------------------------------+

#  {#section .Closing .unnumbered}