The RISKS Digest
Volume 13 Issue 52

Wednesday, 27th May 1992

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Yellow Slime Shuts Down Munich Opera
PGN
"Programming error" prevents long distance billing
Bob Robillard
White House Fights to Erase E-Mail Backups
Randy Gellens
Critical technologies
Martyn Thomas
Re: Not enough trained computer experts
Robert Dorsett
Provisional program DCCA-3
Luca Simoncini
Info on RISKS (comp.risks)

Yellow Slime Shuts Down Munich Opera

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 27 May 92 15:08:05 PDT
The computer-controlled hydraulic system for the stage at the Munich Opera is a
wonder of modern technology, controlling all rolling side stages, platforms,
flats and panels.  It is the ultimate play-by-wire system and for many
explicitly programmed operas the show cannot go on without it.  The problem is
that the hydraulic fluid used in the new system (circulating in the old water
pipes) is 50,000 liters of ecologically correct Quintolubric oil, made in the
Netherlands.  Unfortunately, it is biodegradable, and the bacteria left over
from the old pipes love it.  The result is a nasty yellow slime that multiplies
fruitfully.  The repertory has been trimmed dramatically, excluding those works
that cannot be performed without it, and reducing some others to concert
versions.  Some performances have had to be halted in mid-scene, which requires
cleaning all vents and filters.  Audiences are upset.  The cost to fix the
problem (presumably to replace all the pipes and change the oil to something
ecologically less sound) is estimated at $24M.  [Source: A NY Times article by
John Rockwell, seen in the San Francisco Chronicle, 26 May 1992, p.E2]

   [Could be messy if the Slime Disease gets into the Orchestra Pit.
   What productions would be appropriate under these circumstances?
   The Wizard of Ooze and the Yellow Bic Flowed?   El AMARILLO cid?
   JAUNE of Arc?   Der GELBrosenkavalier?   The Russo-Japanese KI'IROI Ballet?
   Something by Norman Dello GIALLO?  Certainly something Polish conducted
                 ./
   by Sir George ZOLTY?  Pictures at an Exhibition by de KUNING in Indonesia?
   (In case you are puzzled, there is something yellow in every one of those,
   even ASFAR as the eye can see in the arabian desert.)  I'm not yellow, but
   I thought I'd try out some multilingual puns on our multilingual readers in
   remote sites.  I've been too kind in recent times, but not off color.  PGN]


"Programming error" prevents long distance billing

Bob Robillard <duke@ctt.bellcore.com>
Fri, 22 May 92 12:35:23 EDT
  THOUSANDS DIAL LONG-DISTANCE 'FREE' AS A COMPUTER GLITCH HANGS UP BELL
               Star Ledger:Newark-NJ, 22 May 1992, p.1

New Jersey Bell officials said yesterday that thousands of New Jersey Bell
customers have been dialing long-distance between February 17 and April 27
without being billed for any of the calls. The situation, involving about two
million calls, was blamed by New Jersey Bell on an internal programming error.
The error affected 15 exchanges in the state and blanketed all direct-dialed
calls made through AT&T.  New Jersey Bell said the calls were registered and
customers will eventually be back-billed, which could result in some large
telephone bills. However, an AT&T spokesperson said customers could contact New
Jersey Bell to "arrange a flexible billing arrangement so there is no financial
hardship."


White House Fights to Erase E-Mail Backups

<MPA15AB!RANDY@trenga.tredydev.unisys.com>
21 MAY 92 02:23
From a story by Paul Houston in the L.A. Times 20 May 1992:

Two days before President Bush took office, a researcher discovered that the
new Administration planned to erase computer backup tapes containing thousands
of messages sent by "electronic mail" [sic] throughout the White House of
departing President Ronald Reagan.

The report alarmed groups representing historians and reporters, who for
decades have been able to go to the National Archives and plow through the
records of past Administrations, gaining valuable insight into how policies
were formed and carried out.

The groups knew that some E-mail tapes already had been shown to carry
incriminating messages between former National Security Advisor John M.
Poindexter and his aide, Oliver L. North, in the Iran-Contra scandal.

Fearing that much more treasure was about to vanish in this new electronic age,
one group immediately filed suit and won a temporary order preserving many
tapes.  That ignited a far-reaching clash between researchers and the Bush
Administration that is finally coming to a head Friday in federal court.

At stake is not only past tapes but present ones, which are being regularly
erased before unknown numbers of messages can be printed out and saved for the
National Archives.

"We are probably losing fascinating snatches of things that provide
illumination and point you in new directions," laments Robert J. Donovon, who
has written histories of former Presidents Harry S. Truman, Dwight D.
Eisenhower and John F. Kennedy.

BACKGROUND:  The federal Records Act requires that "all books, papers, maps,
photographs, machine readable materials" dealing with government "policies,
decisions, procedures, operations" be preserved for the National Archives.

In 1978, Congress made clear that the law applied to presidential records,
including "electronic or mechanical recordations."  The move blocked an attempt
by former President Richard M. Nixon to control--and theoretically destroy--all
tapes of conversations between him and his staff that had led to his
resignation in the Watergate scandal.

When the Iran-Contra affair broke in 1987, investigators searched White House
computer tapes for messages involving Poindexter, North and other White House
aids.  The aides thought they had erased the messages--but many were preserved
on backup memory [sic] tapes.

One message that has been made public concerned a 1986 meeting at which North
later admitted he lied to a group of congressmen about his support of the
Nicaraguan Contras.  A Poindexter aide reported by E-mail that "session was
success," with North saying that he "gave no military advice" to the Contras.
Poindexter forwarded the note to North, attaching an E-mail message of his own
that said: "Well done."

ISSUES:  "The Administration would call those two words a mere telephone
message slip," and not a record that must be preserved, says Thomas Blanton,
head of the National Security Archive, a research center that filed the pending
suit.  "But a historian would say those words give the whole picture of
suborning testimony to Congress," he added.

The plaintiffs contend that the records preservation law clearly covers E-mail
and that the head archivist has sole authority to determine which White House
messages should be kept for posterity.

Justice Department attorneys respond that a White House manual--leaving it to
aides to decide which E-mail should be printed out for safekeeping--is
sufficient to comply with the law.  Most of the messages are personal or
trivial anyway, the attorneys contend.

The plaintiffs have asked U.S. District Judge Charles Richey to order the
Administration to turn over a large sampling of E-mail from the Reagan years so
he can determine whether it--and by extension, much subsequent E-mail--should
be preserved.  Richey is expected to rule on the request Friday.

Randy Gellens   randy%mpa15ab@trenga.tredydev.unisys.com [THIS BOUNCES FOR PGN]
   OR forward to postmaster@tredysvr.tredydev.unisys.com


Critical technologies

Martyn Thomas <mct@praxis.co.uk>
Tue, 26 May 92 13:25:49 BST
Did I miss an earlier discussion of the March 1991 Report of the (US) National
Critical Technologies Panel?

The software section makes depressing reading.  Complexity is identified as the
problem.  CASE is identified as The Answer.

Under "Innovative Concepts", two are identified: rapid prototyping and modular
software.  (Perhaps this section got left in from a report a decade earlier, by
mistake :-)

The impossibility of exhaustive testing is identified, yet testing is seen to
be the answer! "Intensive efforts are underway to develop advanced testing
tools that attempt to simulate the broadest possible set of conditions in which
a program might operate.  By reducing manual quality control requirements, these
tools have the potential to greatly shorten the software development cycle and
reduce development costs".  By juxtaposition, this is set as the solution to
"complex software cannot be exhaustively tested prior to release".

The section ends: "The central challenge in software development is automated
code generation for sophisticated programs. The development of such tools is
largely dependent upon artificial intelligence and other software-based
technologies. ... ...".

The Risk? That someone might actually believe this stuff (although I concede
that it seems unlikely).

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   mct@praxis.co.uk


Re: Not enough trained computer experts (FBCohen, RISKS-13.51)

Robert Dorsett <rdd@cactus.org>
Thu, 21 May 92 02:32:37 CDT
I think there's a gigantic conceptual leap from the skepticism that people
may have that an extant system (UNIX, in this case) can be reliably hacked
to be something that it wasn't intended to be--secure--to extrapolating that
to a broad notion that the ground-up design of a secure system is impossible.
There are bases for both viewpoints: what actually happens has largely to
do with the usual design trade-offs of features vs. functionality, and how
much money the developing agency has to throw at the problem.

UNIX, with its historically anarchic functional development, and relatively
simple OS, is a particularly bad example to be using.  Yeah, there are lots
of people at work developing secure UNIX, but I have doubts as to what's
being done to the OS to pull it off.  What they produce might run a shell,
all the right software, and keep the bogiemen out, but the hackwork that's
involved is pretty impressive.  And hackwork tends to produce unforeseen
effects: thus a never-ending cycle of fixes and hacks, to plug those
unforeseen problems, in an ever-increasingly complex OS.  It's no wonder
people are skeptical.

Changing the fundamental emphasis of an aspect of an existing complex software
system-- in this case, changing the "security" emphasis of UNIX to keeping
errant Russians out, from keeping errant students or casual intruders out--is
always more tricky than designing a system designed for a SPECIFIC emphasis
from scratch.

>  How come
>we never hear on the risks forum about any successes where the computer
>security system saves people?

Why should we?  We all know such systems exist.  Or, at least, we hope
they exist.  I'm not willing to adjudge any complex program *I* write as
"100% reliable."  Notwithstanding logical or semantic errors, there are many
ways in which a language can be misinterpreted or misimplemented by a given
compiler.  What's the cut-off point at which we can claim to judge a section
of code "reliable"?  100,000 lines?  50,000 lines?  10 lines?  Is an ag-
gregate of such reliable segments in itself reliable?  You tell me.

The *problems* occur where systems fail.  It's way too easy to fall into a
see-no-evil, hear-no-evil mindset, which seems to be precisely that which
your advertisers--who you're complaining about--wish to propagate!
It is my perception that the risks forum was intended *precisely* to offer an
alternative to the widespread propagation of such attitudes in the industry.
It serves an important purpose: to show people (including a great many
students, not yet a part of the Real World) that the spec sheets can't always
be believed; that sloppy, cheap design is all too often the order of the day;
and that ideal, elegant solutions don't always get done right in the real
world.  We can read about elegant solutions in the journals, or have them
ordained from some professor, any time.

>nuclear reactor stories where human error was detected and corrected by a
>computer and saved us from a meltdown?

But isn't it so much more productive to concentrate on cases where such
meltdowns were averted only by the last level of redundancy?  And then
debate why higher levels of redundancy failed?  The possibility of the
last level of redundancy failing NEXT time is so unacceptable that we
can't possibly take time off and thank our lucky stars that we got it
right, this time.  Safety-critical systems require--DEMAND--INTENSE
scrutiny and criticism.

>So, this whole thing was inspired by the British story about BA incidents.

But don't forget the two pilots in the cockpit, monitoring the instruments,
*waiting* for the all-important comparator or autopilot annunciator to
indicate a failure state, and ready, at the first sign of trouble, to
CLICK IT OFF and go around.  This being the sole emphasis of all their
training: the determination of the point when a situation's going to hell,
and what to do.  An integral part of the *safety* checks of the system.
THAT thought makes me comfortable, through a landing in weather I wouldn't
be caught driving a car in.  Unfortunately, though, I KNOW airline pilots
who have too much faith in the automation, who expect it to do what they tell
it to, who view it as an abstract entity that "does" things, and not merely a
machine, a collection of parts, decisions, and compromises, a machine
which, like all machines, can FAIL.  They are trained like any other airline
pilot, but can spend lifetimes with no fundamental problems, and get sloppy.
Those pilots (and their passengers) DIE when they get too far behind the
airplane, and rely on the computer to do their job.  And lo and behold, the
747-400, which makes such wonderful landings, has a cockpit environment so
secure, so amazing, that it's almost tailor-made to produce such attitudes.

But I know: the solution to sloppy pilots in automated cockpits is to increase
the automation ("Hey, we can do it!"), to protect us from the pilots (ala
A3[2-4]0 FBW), which, in turn, can produce even more isolated, insulated
attitudes, thus producing even more fundamental mistakes.  Ad nauseum.

Enjoy your next flight. :-)

>The point is that the reason we don't have enough experts to do QA is that we
>don't teach that stuf in schools, we punish those who follow that line (as a
>society),

I think you're mistaken.  The sole reason that highly robust systems are not
pursued, whether it be operating systems or retail-vertical software, is money.
Cheap solutions that fit the customer or marketing specification, that don't
break too often, are the order of the day.  When companies are willing to spend
more money on development--and research on methods, and training decent
software engineers, and willing to postpone release a couple of years when the
production process--which is an art, not a science, and not amenable to Harvard
Business School management tactics--bogs down, AND society's willing to
shoulder the extra costs all that will engender: THEN we'll have something to
talk about. :-)

I can see what you're saying, but I don't think your position's very
productive.  Several times a year, RISKS sees "lighten up!" posts, but
let's keep the name and charter of the digest in mind.

Perhaps we need a "USA Today" version of RISKS, a respite for when the gloom
and doom becomes a bit much. :-)

Robert Dorsett  rdd@cactus.org  ...cs.utexas.edu!cactus.org!rdd


Provisional program DCCA-3

Luca Simoncini <simon@mv3500.iet.unipi.it>
Mon, 25 May 92 16:14:41 -0100
DCCA-3 Preliminary Program, 3rd IFIP Working Conference on
DEPENDABLE COMPUTING FOR CRITICAL APPLICATIONS

Can We Rely on Computers?

Splendid Hotel La Torre, Mondello (Palermo), Sicily, Italy,
14-16 September 1992

Organized by
  IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance
In cooperation with
  IFIP Technical Committee 11 on Security and Protection in Information
  Processing Systems
  IEEE Computer Society Technical Committee on Fault-Tolerant   Computing
  EWICS Technical Committee 7 on Systems Reliability, Safety and    Security
  University of Pisa
  Istituto di Elaborazione dell'Informazione del CNR, Pisa
  Associazione Italiana per l'Informatica ed il Calcolo Automatico
With the support of
  ITALTEL S.p.A, ANSALDO TRASPORTI, C.N.R. Comitato Nazionale   Scienze e
Tecnologie dell'Informazione, Comune e Provincia di     Palermo

General Chair
  L. Simoncini, University of Pisa, Italy
Program co-Chairs
  C.E. Landwehr, Naval Research Laboratory, USA
  B. Randell, University of Newcastle upon Tyne, UK
Local Arrangement and Publication Chair
  E. Ricciardi, IEI-CNR, Italy
Program Committee
  J.A. Abraham, U of Texas, USA
  P. Bishop, National Power, UK
  A. Costes, LAAS-CNRS, France
  D. Craigen, Odyssey Research, Canada
  K. Dittrich, U of Zurich, Switzerland
  H. Ihara, Hitachi, Japan
  R.K. Iyer, U of Illinois, USA
  J.P. Kelly, U of California, USA
  R. Kemmerer, U of California, USA
  H. Kopetz, Technische U Wien, Austria
  J.H. Lala, CS Draper Lab, USA
  K. Levitt, U of California, USA
  B. Littlewood, City U, UK
  T. Lunt, SRI Int'l, USA
  J. Meyer, U of Michigan, USA
  M. Morganti, Italtel, Italy
  S. Natkin, CNAM, France
  J-J. Quisquater, Philips, Belgium
  R.D. Schlichting, U of Arizona, USA
  F.B. Schneider, Cornell U, USA
  D. Siewiorek, Carnegie-Mellon U, USA
  L. Strigini, IEI-CNR, Italy
  I. Sutherland, ORA, USA
  W.M. Turski, Warsaw U, Poland
Ex Officio
  J-C. Laprie, LAAS-CNRS, France, IFIP WG 10.4 Chair

This is the third Working Conference on this topic, following the successful
conferences held in August, 1989, at Santa Barbara (USA) and in February, 1991,
at Tucson (USA). As evidenced by papers that were presented and discussed at
those meetings, critical applications of computing systems are concerned with
differing service properties, relating to both the nature of proper service and
the system's ability to deliver it. These include thresholds of performance and
real-time responsiveness that demark loss of proper service (failure),
continuity of proper service, ability to avoid catastrophic failures, and
prevention of deliberate privacy intrusions.

The notion of dependability, defined as the trustworthiness of computer service
such that reliance can justifiably be placed on this service, enables these
various concerns to be subsumed within a single conceptual framework.
Dependability thus includes as special cases such attributes as reliability,
availability, safety, and security. In keeping with the goals of the previous
conferences, the aim of this meeting is to encourage further integration of
theory, techniques, and tools for specifying, designing, implementing,
assessing, validating, operating, and maintaining computer systems that are
dependable in the broad sense. Of particular, but not exclusive interest, are
presentations that address combinations of dependability attributes, e.g.
safety and security, through studies of either a theoretical or an applied
nature.

As a Working Conference, the program has been designed in order to promote the
exchange of ideas by extensive discussions. All the paper sessions will end
with a 30 minute discussion period on the topics dealt with in the session. In
addition to the paper sessions, three panel sessions have been organized. The
first, entitled "Safe Vehicle-Highway Systems" will explore safety
requirements, design methods and validation techniques for computing and
communication subsystems associated with intelligent vehicle-highway systems.
The second, entitled "Malicious and Inadvertent Human Operator Faults" will
explore current and proposed techniques for detecting and countering faults
introduced by the human operator. The third, entitled "Security Issues in
Intelligent Networks" will deal with privacy problems related to the delivery
of intelligent network services and related customer control, along with
network security problems mostly related to open network provisioning.

Advance registration as well as hotel reservation is required. No on-site
registration will be available.

Sunday September 13
Welcome Reception (7.00 - 10.00 p.m.), Hotel La Torre

Monday September 14
Opening Remarks (8.30 a.m.)
  L. Simoncini, General Chair
  C.E. Landwehr, B. Randell, Program Co-Chairs

Session 1: Functional Testing (9.00 a.m)
  On Functional Statistical Testing Designed from Software Behavior Models
    P. Thevenod-Fosse, H. Waeselynck (LAAS-CNRS, France)
  Functional Test Case Generation for Real-Time Systems
    D. Mandrioli, A. Morzenti (Politecnico di Milano, Italy),
    S. Morasca (University of Maryland, USA)

Break (10.30 a.m.)

Session 2: Specification and Verification of Fault Tolerance (11.00 a.m.)
  Design for Dependability
    J. Nordahl (Technical University of Denmark, Denmark)
  Tracing Fault Tolerance
    H. Schepers (Eindhoven University of Technology, The Netherlands)

Lunch (12.30 p.m.)

Session 3: Dependability and Performance (2.00 p.m)
  Evaluation of Fault-Tolerant Software: A Performability Modeling Approach
    A.T.Tai, A. Avizienis (University of California at Los Angeles, USA)
  Performance Analysis of Rollback Recovery in Process Control Systems
    A. Ranganathan, S.J.Upadhyaya (State University of New York at Buffalo, USA)
  On the Transient Analysis of Stiff Markov Chains
    J. Dunkel, H. Stahl (Universitat Dortmund, Germany)

Break (4.00 p.m.)

Panel Session 1: Safe Vehicle-Highway Systems (4.30 p.m.)
  Moderators: A. Costes (LAAS-CNRS, France), J.F. Meyer (University of Michigan, USA)

Tuesday September 15
Session 4: Application of Formal Methods (9.00 a.m)
  Formal Techniques for Synchronized Fault-Tolerant Systems
    B.L. Di Vito (Vigyan Inc., USA), R.W. Butler (NASA Langley Research Center, USA)
  Compiler Correctness and Input/Output
    P. Curzon (University of Cambridge, U.K.)

Break (10.30 a.m.)

Session 5: Online Error Detection (11.00 a.m.)
  Control Flow Checking In Object-Based Distributed Systems
        N.A. Kanawati, G.A. Kanawati, J.A. Abraham (University of Texas at Austin, USA)
  Time Behavior Monitoring as an Error Detection Mechanism
    H. Madeira, P. Furtado, J.G. Silva (University of Coimbra,Portugal)

Lunch (12.30 p.m.)

Session 6: Safety-Critical Industrial Systems (2.00 p.m)
  A "Strongly-Fail-Safe Majority Voted Output" Circuit used for Designing
  Dependable Computer Systems
    S. Noraz, M. Prunier (Merlin Gerin Company, France)
  ACC: Dependable Computing for Railway Control Systems
    G. Mongardi (Ansaldo Trasporti, Italy)

Break (3.30 p.m.)

Panel Session 2: Malicious and Inadvertent Human Operator Faults (4.00 p.m.)
  Moderators: J.C. Laprie (LAAS-CNRS, France), T. Lunt (SRI International, USA)

Banquet (8.00 p.m.)

Wednesday September 16
Session 7: Experimantal Evaluation (9.00 a.m)
  A Hybrid Monitor Assisted Fault Injection Environment
    L.T. Young, R.K. Iyer (University of Illinois at Urbana-Champaign, USA)
  Space/Time Overhead Analysis and Experiments with Fault-Tolerant Techniques
    L.A. Laranjeira, M. Malek, R. Jenevein (University of Texas at Austin, USA)

Break (10.30 a.m.)

Panel Session 3: Security Issues in Intelligent Networks (11.00 a.m.)
  Moderator: M. Morganti (Italtel S.p.A., Italy)

Lunch (12.30 p.m.)

Session 8: Protocols for Dependability (2.00 p.m)
  Primary-Backup Protocols: Lower Bounds and Optimal Implementation
    N. Budhiraja, K. Marzullo, F.B. Schneider, S. Toueg (Cornell University, USA)
  A Linguistic Framework for Dynamic Composition of Fault-Tolerance Protocols
    G. Agha, S. Frolund, R. Panwar, D. Sturman (University of Illinois at
        Urbana-Champaign, USA)
  Using Two-Phase Commit for Crash Recovery in Multilevel Secure
  Distributed Database Management Systems
    S. Jajodia, C.D. McCollum (The Mitre Corporation, USA)

Conclusions (4.00 p.m.)

LOCATION: Splendid Hotel La Torre, Via Piano Gallo 11, Mondello, Palermo,
Sicily, Italy Tel.: + 39 91 450222 ( or +39 91 450312) Fax: +39 91 450033.

HOW TO REACH MONDELLO: There are direct flights to Palermo from Paris, Munich,
Rome, Milan and Pisa. From Palermo Airport take either a taxi to the Hotel or
take the shuttle bus to the City Terminal in central Palermo, from where buses
are available to reach the Hotel in Mondello.

SOCIAL EVENTS AND ARRANGEMENTS: During the Conference, the following events
have been organized for participants and accompanying persons: * SUNDAY,
SEPTEMBER 13 (7.00 p.m.): Participants are invited to a Welcome Reception at
the Hotel La Torre.  * TUESDAY, SEPTEMBER 15 (8.00 p.m.): The Banquet is kindly
offered by APT Azienda Provinciale per il Turismo, Palermo.  Buses will take
the participants to the Banquet and then back to the Hotels.  The price for
Accompanying persons wishing to attend the Banquet is It. Lire 80000.

LUNCH: Lunches will be served at the Hotel La Torre.  The price per lunch for
Accompanying persons is It. Lire 35000.

TELEPHONE AND FAX MESSAGE: Participants may receive messages during the
Symposium at the Hotel La Torre ( see LOCATION ).

CONTACT ADDRESS: For any information write to:

Ettore Ricciardi: IEI-CNR, Via Santa Maria, 46,  56126  Pisa, Italy
Telex 590305 IEICNR I  Fax + 39-50-554342  E-mail SIMON@ICNUCEVM.CNUCE.CNR.IT

DCCA-3, September 14-16, 1992

REGISTRATION FORM

Surname
Name
Affiliation
Address
City
State:          Zip
Tel.:           Fax:
E- mail.

REGISTRATION FEES

PRE-REGISTRATION IS REQUIRED. NO ON-SITE REGISTRATION

Before July 15, 1992:   Lit. 380,000
Before August 15, 1992:    Lit. 450,000

PAYMENT
AMOUNT OF LIT.
...............................................................

    I enclose an International Bank cheque for the total amount indicated
above.
    I enclose photocopy of a bank transfer order (bonifico)

payable to: DCCA-3 Ettore Ricciardi, Bank Account n. 13761
                Banca Popolare di Novara Ag. 1, Via S. Francesco,54- Pisa

Send in an envelope to: Ettore Ricciardi, IEI-CNR, Via Santa Maria, 46,
56126 Pisa, Italy

3rd IFIP Working Conference on Dependable
Computing for Critical Applications DCCA-3

September 14-16, 1992

HOTEL RESERVATION FORM
Surname:
Name
Affiliation
Address
City
State           Zip
Tel.:           Fax.

Accompanied by (surname and name)

I wish to share a double room with

Date of
arrival...........Departure.............Tot..........
Nights..........

Please return this form
before July 31, 1992 to: Ettore Ricciardi, IEI-CNR, Via Santa Maria, 46
56126 Pisa, Italy

No deposit is required. The Hotel bill will be settled directly with the Hotel.
Major credit cards are accepted.  A limited block of rooms has been reserved
for participants to the Conference.  Participants, whose Hotel Reservation Form
arrive after July 31, 1992, may have to be accomodated in nearby Hotels.  EARLY
HOTEL RESERVATION IS STRONGLY SUGGESTED. THE RESERVATIONS WILL BE PROCESSED IN
STRICLY FIRST ARRIVED FIRST SERVED WAY.  Extension of the stay is possible at
the same cost conditions.

3rd IFIP Working Conference on Dependable
Computing for Critical Applications DCCA-3

September 14-16, 1992

ACCOMMODATION:
Single
Lit. 103000
no............
Double
Lit. 156000
no............
Triple
Lit. 202000
no............
Double as Single
Lit. 120000
no............
Please mark the accommodation  you wish to reserve.

N.B.
*Prices indicated are per, including breakfast, service charges,taxes and VAT;
*All bedrooms have private shower or bath;
*When single rooms are no longer available, double rooms for single use will
 be reserved;
*Major credit cards are accepted;
*The fee remitted will be refunded, minus one day room cost, if written
notification of cancellation arrives before September 1, 1992. Thereafter no
refund will be permitted;
*The Hotel Management must be informed of changes to arrival time; rooms will
be considered booked until 6.00 p.m. on date indicated on the Hotel Reservation
Form and will be reserved until later only upon notification.
=============================================================
Luca Simoncini, Dipartimento di Ingegneria dell'Informazione,
Universita' di Pisa, Via Diotisalvi 2, 56100 Pisa, ITALY
tel. +39 50 568667 (direct) +39 50 568511 (switching)
fax. +39 50 568676 (direct) or +39 50 568522 (secretary)
E-mail: SIMON@IET.UNIPI.IT
=============================================================

Please report problems with the web pages to the maintainer

x
Top