The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 1 Issue 15

Friday, 20 Sep 1985


o SDI Panel at 8th ICSE in London (David Weiss) Risks to the Moderator (PGN) Mailer Protocol Woes (Marty Moore) Another Horror Story — Sidereal Time Rollover (Marty Moore) Article: Health Hazards of Computers (Ted Shapin) Two More SDI Related Queries (douglas schuler) CAL ID — computerized fingerprint system
douglas schuler

SDI Panel at 8th ICSE in London

David Weiss <wanginst!>
Wed 18 Sep 1985 16:51:10 EST

    Panel Discussion on the Strategic Defense Initiative at the 8th
         International Conference on Software Engineering

One of the more interesting sessions at the 8th International
Conference on Software Engineering was a discussion of software for
the Strategic Defense Initiative (SDI).  The moderator was Manny
Lehman and the panelists were Fred Brooks, David Parnas, and Alan
Perlis.  The discussion was originally intended to be a debate, but
Fred Brooks was not willing to participate in a debate because he had
not yet reached a resolution of the issues.  (I understand that
volunteers for the position of opposing Parnas in a debate on SDI
were hard to find.  Dr. Brooks deserves credit for being willing to
engage in a public exploration of touchy issues about which he feels
unsettled in concert with a strongly opinionated colleague in an
effort for both audience and panel to learn more.)

The discussion started with a presentation by Parnas of the technical
reasons why reliable SDI software cannot be built.  (Readers of this
newsletter will be familiar with many of the arguments put forth by
Parnas.  A complete discussion in hard-copy is available from him at
the University of Victoria, Department of Computer Science, P.O.  Box
1700, Victoria, B.C., Canada.)

Brooks responded with reasons why he thought we could build such a
system.  His major point was that we have built similar systems in
the past.  He identified the Apollo missions software as an example,
suggesting that we start with such a system and incrementally build
from it towards an SDI system, using what's learned along the way.

Perlis then added a few comments, explaining why SDI software would
be more complex than existing software and why it is of the hardest
type of software to build.  His argument was that the SDI system
represents a moving target in terms of requirements and design.

Following some further discussion among the panelists the floor was
opened to technical questions from the audience.

The major place in which Parnas and Brooks seemed to disagree was
whether or not similar systems have been built.  Brooks tried to use
the Apollo and Space Shuttle as examples.  Parnas's point was that in
those systems everything can be predicted in advance.  In an
anti-missile system, the number, shape, and trajectories of launched
missiles can't be predicted.  In addition, the system must
distinguish decoys from real warheads.  Finally, the defense system
itself will be under attack.  As a result, realistic tests and
simulations of operating conditions for such a system could not be

All the discussants seemed to agree that an SDI system could not be
built error-free, and that it would not be completely reliable.
Nonetheless, there were advocates of building it on such grounds as
that it would only be needed for a short time, and could be turned
off the rest of the time, or that we now place our trust in systems
that are also untested and probably unreliable.

In summary, there were no good responses to any of the questions that
Dave Parnas raised.  Nonetheless, there were arguments put forth for
the construction of an SDI system on the grounds that it need not be
completely reliable.

David Weiss
Wang Institute of Graduate Studies

Risks to the Moderator!

Peter G. Neumann <Neumann@SRI-CSLA.ARPA>
Thu 19 Sep 85 17:40:08-PDT

RISKS-1.15 was ready to go out Wednesday night.  Murphy hit in spades.  The
SRI MICOM switch for dial-up access was unavailable for two days, and is
still down.  An alternative route might have been available through the only
system that receives dial-ups directly from a split-speed modem, but that
system went down for five hours.  Several other more circuitous alternative
routes all ran into broken gateway, which resulted from a power failure
Tuesday night.  It would not have helped to drive back to SRI, because the
SRI-CSLA (which kept running through all this) was out of net contact as a
result of a gateway problem.  All of the gurus were invisible.  If you ever
get this issue, you will know that things have improved.  Peter

Please report problems with the web pages to the maintainer