![](media/image1.wmf)

ILC-doc-305-v2

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 improve some of the look and
feel issues that have been raised and to ensure that the CRL is deployed
in a fashion that best suits the needs of the project..

**Table of Contents**

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

[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](#__RefHeading___Toc139387788)

[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 9](#psi-elog)

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

[6.3.1 Pro 9](#__RefHeading___Toc139387794)

[6.3.2 Con 9](#__RefHeading___Toc139387795)

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

[6.4.1 Pro 9](#__RefHeading___Toc139387797)

[6.4.2 Con 9](#__RefHeading___Toc139387798)

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

[6.5.1 Pro 10](#__RefHeading___Toc139387800)

[6.5.2 Con 10](#__RefHeading___Toc139387801)

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

[6.6.1 Pro 10](#pro-3)

[6.6.2 Con 11](#__RefHeading___Toc139387804)

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

[6.7.1 Pro 11](#pro-4)

[6.7.2 Con 11](#con-4)

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

[6.8.1 Pro 12](#pro-5)

[6.8.2 Con 12](#con-5)

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

[6.9.1 Pro 12](#pro-6)

[6.9.2 Con 12](#con-6)

[7 Recommendation 13](#recommendation)

[Levels of Support 13](#__RefHeading___Toc139387815)

[7.1 13](#section)

[A. What About Hosting the Elog from DESY?
14](#__RefHeading___Toc139387817)

[B. Change Log 14](#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. 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, regarless 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. 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 it's
    use is declining due to support problems.

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

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 the host site to share the source 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; the committee also
> imagines that 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 thought about a 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. None of the candidates currently
    has modern, secure authentication.

4.  Source code must be available.

5.  It must be possible to use the elog using 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.  

8.  

9.  

10. 

11. 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, displaying
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, that 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 in the 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 tkl 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 and in-lined figure;
inspection of logbooks used at Fermilab 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 some 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: just search 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. 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 mission for which AD Elog was designed is less
ambitious the mission now being considered; 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 it 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
which 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 (using 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 operates servers hosting the CRL for
several experiments. They provide 24/7 support for these servers and 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 searched.

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 over 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; attachments
can and should be searched.

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

There are several points in favour of chosing 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;
moreovcer, 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.

## Levels of Support

## 

Suzanne Gysin estimates the effort required to make the upgrades in the
CRL at about 0.5 FTE of 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 features to add to the CRL can be grouped in a set of large
features:

> Security (PKI/Kerberos/SSL)
>
> Entry Text Indexing for word searching (Lucene)
>
> Quicker and easier Deployment\
> Allow Images in Annotations

And a set of minor features are:

> Background color and font size options
>
> Allow more image formats for thumbnailing (TIFF)
>
> Attach images to Process Logger

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 that will need some discussions with the CRL
developers to make these choices wisely.

A.  What About Hosting the Elog from DESY?

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, only the downside that the use
of the TTF remotely may require more support than we 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. It seems to the
committee that the interest in this feature is only a appropriate in the
longer term. 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; is
DESY willing to support elogs from Fermi for projects not related to the
ILC? Is the network availability and bandwidth sufficient.

# Change Log {#change-log .Closing}

  ------------- ------------ -----------------------------------------------
  **Version**   **Issue      **Description Of Change**
                Date**       

  1                          Initial Revision

  2                          Comments from Suzanne. Appendix A added.

  3                          
  ------------- ------------ -----------------------------------------------

#  {#section-1 .Closing .unnumbered}