Subject: RISKS DIGEST 13.52 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 27 May 1992 Volume 13 : Issue 52 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator 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) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Wed, 27 May 92 15:08:05 PDT From: "Peter G. Neumann" Subject: Yellow Slime Shuts Down Munich Opera 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] ------------------------------ Date: Fri, 22 May 92 12:35:23 EDT From: Bob Robillard Subject: "Programming error" prevents long distance billing 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." ------------------------------ Date: 21 MAY 92 02:23 From: Subject: White House Fights to Erase E-Mail Backups 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 ------------------------------ Date: Tue, 26 May 92 13:25:49 BST From: Martyn Thomas Subject: Critical technologies 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 ------------------------------ Date: Thu, 21 May 92 02:32:37 CDT From: rdd@cactus.org (Robert Dorsett) Subject: Re: Not enough trained computer experts (FBCohen, RISKS-13.51) 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 ------------------------------ Date: Mon, 25 May 92 16:14:41 -0100 From: simon@mv3500.iet.unipi.it (Luca Simoncini) Subject: Provisional program DCCA-3 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 ============================================================= ------------------------------ End of RISKS-FORUM Digest 13.52 ************************