TAB YEAR 2000 TECHNICAL INFORMATION FOCUS GROUP

Piscataway, NJ, June 9, 1999.

To: Members, Senate Commerce, Science And Transportation Committee;

Members, Special Senate Committee On The Year 2000 Technology Problem;

Members, House of Representatives Committee on Science, Subcommittee on Technology;

Members, Committee on Government Reform, Subcommittee on Government Management Information, and Technology;

Sponsors, House Bill `Year 2000 Readiness and Responsibility Act of 1999,' H.R. 775.Re: Year 2000 Liability Legislation.

From: The Institute of Electrical and Electronics Engineers ( IEEE ) Technical Activities Board Year 2000 Technical Information Focus Group.

Dear Honorable Senators, Congressmen and Congresswomen:

As leaders of the Y2K effort of the Institute of Electrical and Electronics Engineers ( IEEE ) , the oldest and largest international non-profit association of engineers and computer scientists in the world, we would like to offer some thoughts on the pending legislation involving Y2K liability obtained from our years of work and collective wisdom spent studying Y2K. The IEEE has drafted an Institute position on Y2K Legal Liability regarding United States federal law, to which our committee greatly contributed. We offer these additional thoughts in hopes that they may further assist your understanding as you attempt to reconcile two very valid but conflicting underlying public policy goals in structuring and passing the Year 2000 Liability Legislation currently under consideration.

Minimize Damage to the Economy and Quality of Life: minimize the overall damage to the nation's economy and quality of life by reducing the need of organizations to redirect their limited resources away from the task of maintaining their operations in the face of Y2K in order to defend themselves from lawsuits arising from alleged Y2K failures.

Maximize Incentive for Y2K Failure Prevention: maximize the incentive of every organization to prevent Y2K failures as well as preserve the legal rights and remedies available for those seeking legitimate redress for wrongs they may suffer resulting from Y2K failures.

In addressing public policy issues we have no more expertise than the literate public. However, we do possess expertise in the technical issues underlying the situation that should be considered as you weigh the conflicting public policy goals in formulating appropriate Year 2000 Liability Legislation. In particular, for your consideration we offer the following points pertaining to the technical realities of Y2K.

1. Prevention of all Y2K Failures Was Never Possible: For many large and important organizations, technical prevention of all Y2K failures has never been possible in any practical way for these reasons:

1.1 `Y2K Compliant' Does Not Equal `No Y2K Failures.' If an organization makes all of its systems `Y2K compliant', it does not mean that that same organization will not experience Y2K failures causing harm to itself and other organizations. In fact, efforts to become `Y2K compliant' in one place could be the direct cause of such failures in others. If interconnected systems are made compliant in different ways, they will be incompatible with each other. Many systems in government and industry are mistakenly being treated as if they were independent and fixed in the most expedient way for each of them. When this `Humpty Dumpty' is put back together again, it will not work as expected without complete testing, which is unlikely ( see Complexity Kills below ) .

1.2 All Problems Are Not Visible or Controllable. In the best case organizations can only address those things they can see and those things they have control over. Given this reality, many Y2K failures are inevitable because some technical problems will not be discernible prior to a failure, and others, while discernible, may not be within an organizations' jurisdictional control to correct. This is especially true in large complex organizations with large amounts of richly interconnected software involved in long and complex information chains and in systems containing a high degree of embedded devices or systems purchased in whole from external parties. ( The temporary lifting of certain copyright and reverse engineering restrictions for specific Y2K protection efforts should also be considered as long as copyright holders are not unduly harmed. )

1.3 Incoming Data May Be Bad or Missing. To maintain their operations many organizations require data imported from other organizations over which they have no control. Such data may have unknowingly been corrupted, made incompatible by misguided compliance efforts or simply missing due to the upstream organizations lawful business decisions.

1.4 Complexity Kills. The internal complexity of large systems, the further complexity due to the rich interconnections between systems, the diversity of the technical environments in type and vintage of most large organizations and the need to make even small changes in most systems will overwhelm the testing infrastructure that was never designed to test `everything at once.' Hence, much software will have to be put back into use without complete testing, a recipe, almost a commandment, for widespread failures.

2. Determining Legal Liability Will Be Very Difficult. Traditionally the makers of products that underlie customer operations are liable if those products are `defective' enough to unreasonably interfere with those operations resulting in damage. Y2K is different in that those customers themselves are also at risk for legal action if they fail to fulfill contractual obligations or fail to maintain their stock values and their failure to `fix' their Y2K problems can be shown as the cause. This customer base of technology producers cannot be overlooked in this issue. As it constitutes most of the organizations in the world, its needs and the implications of legislative actions on it considered now should not be overshadowed by undue focus on the much smaller technology producer sector. Nonetheless, even there liability is not as clear as tradition might indicate. Several factors make liability determination difficult, expensive, time consuming and not at all certain.

2.1 There Is a Shared Responsibility Between Buyers, Sellers and Users of Technology. Computer products themselves have only clocks that have dates in them. Application software products usually offer optional ways of handling dates. The customer/user organizations, especially larger, older ones, have created much of their application software in-house. When new products are introduced into the buying organization, the customer/user usually has vast amounts of data already in place that have date formats and meaning already established. These formats and meanings cannot be changed as a practical matter. The majority of, and the longest-lasting, potential system problems lay in application software and the data they process, not in clock functions. ( Clock-based failures, those likely to happen early in January 2000, while potentially troublesome, will be for the most part localized and of short duration. ) Various service providers can be optionally called in to help plan and apply technology for business purposes. But it is only when these are all merged together and put to actual use that failures can emerge. It is very rare that one of them alone can cause a failure that carries legal consequences.

2.2 Many Things Are Outside the Control of Any Defendant. Incoming data from external sources outside its control may be corrupted, incompatible or missing. Devices and systems embedded in critical purchased equipment may be beyond the defendant's knowledge or legal access. Non-technical goods and services the defendant depends upon may not be available due to Y2K problems within their source organizations or distribution channel.

2.3 There Will Be a Strong Defense of Impracticability. Existing large-scale systems were not made safe from Y2K long ago for good reasons. Many systems resist large-scale modernization ( e.g., IRS, FAA Air Traffic Control, Medicare ) for the same reasons. Wide-spread, coordinated modifications across entrenched, diverse, interconnected systems is technically difficult if not impossible at the current level of transformational technology. New products must be made to operate within the established environment, especially date data formats. Technology producers will claim, with reason, that the determining factor in any Y2K failures lay in the way the customer chose to integrate their products into its environment. It will be asserted, perhaps successfully, by user organizations that economic impracticability prevented the prevention of Y2K failures. Regardless of the judicial outcome, it will take a long time and many resources to finally resolve. And that resolution may have to come in thousands of separate cases.

3. Complexity and Time Negates Any Legal Liability Incentive. Even if making all of an organization's systems `Y2K compliant' would render an organization immune from Y2K failures ( it will not ) , the size and complexity of the undertaking is such that if any but the smallest organization is not already well into the work, there is not enough time for the incentive of legal liability to have any discernible positive effect on the outcome. As an analogy, providing any kind of incentive to land a man on Mars within one year would have no effect on anyone's efforts to achieve that unless they had been already working to that end for many years. A negative effect will result from management diverting resources from prevention into legal protection.

4. The Threat of Legal Action Is a Dangerous Distraction at a Critical Time. There will be system failures, especially in large, old, richly interconnected `systems of systems' as exist in the financial services and government sector. The question is how to keep such technical failures from becoming business or organization failures. We should be asking ourselves how we as a society can best keep the flow of goods and services going until the technical problems and failures can be overcome. The following points bear on these questions.

4.1 Y2K Is a Long Term, Not Short Term, Problem. Irrespective of the notion of Y2K being about time, a point in time, or the fixation on the rollover event at midnight December 31, 1999, or even the name `Year 2000' itself, Y2K computer problems will be causing computer system malfunctions and failures for years into the next decade. Y2K is much more about the dates that can span the century boundary represented in data that must be processed by software than it is about any calendar time or clock issues. Because of the vast amounts of these, the complex intertwining among them and our less than complete understanding of the whole, it will take years for the infrastructure to `calm down' after Y2K impacts themselves AND the impacts of the sometimes frantic and misguided changes we have made to it. The current prevention phase is only the beginning.

4.2 Rapid and Effective Organizational Adaptability Will Be a Prime Necessity. They key to an organization's ability to continue to provide the goods and services other organizations and individuals need to continue their operations will be determined by an organization's ability to adapt its practices and policies quickly and effectively in the face of potentially numerous, rapid and unexpected events.

4.3 Lawsuits, Actual or Threatened, Will Divert Requisite Resources. Preventing and minimizing harm to society from Y2K disruption is different than, and at times opposed to, protecting one's organization from legal liability. Addressing lawsuits, and even the threat of a lawsuit, will divert requisite resources, particularly management attention, from an organization's rapid and effective adaptation. This is already happening regarding technical prevention and will get worse the longer such legal threats remain. Organizational management has much more experience dealing with legal threats than they do addressing something as unique and unprecedented as Y2K. Their tendency is to address the familiar at the expense of the novel. They must be allowed to focus on the greater good.

4.4 Judicial System Overload Is Another Danger. Given the great interactive and interdependent complexity of Y2K's impact on the operations of our institutions on a national and global scale, the effort to determine exactly what happened, why it happened and who is legally responsible for each micro-event is itself a huge undertaking requiring the resolution of many questions. For the legal and judicial system to attempt to resolve the legal rights and remedies of affected parties while Y2K impacts are still unfolding will, in any case, threaten to overwhelm the legal and judicial system's capacity to assure justice in the matter, let alone its ability to continue to do its other necessary work.

For all of the reasons discussed above, we support limitations on Y2K-related legal liability. Minimizing harm and assessing blame are each formidable and important tasks, but they cannot be done simultaneously without sacrificing one for the other. Minimizing harm is more important and there is an increased threat to our welfare if assessing blame adversely interferes with our ability to minimize harm. The value of incentives at this late date is very small. We trust that the collective wisdom of Congress will find ways to reduce these threats. We have additional background material available. Please contact IEEE staff contact Paula Dunne if you are interested in this material. We have other ideas beyond the scope of this legislation of what the U.S. federal government can do to help minimize harm throughout this crisis. We are ready to help in any way you may deem appropriate.

Respectfully,

The Institute of Electrical and Electronics Engineers ( IEEE ) Technical Activities Board Year 2000 Technical Information Focus Group.

-- OR (orwelliator@biosys.net), June 22, 1999

Answers

Oh, boy.

Link?

-- Lane Core Jr. (elcore@sgi.net), June 22, 1999.

Ah.

http://www.ie eeusa.org/FORUM/POLICY/99june09.html

-- Lane Core Jr. (elcore@sgi.net), June 22, 1999.

10!

-- y2k dave (xsdaa111@hotmail.com), June 22, 1999.

After such a wonderful assessment, how can anyone believe in anything less than a 7?

DJ

-- DJ (reality@check.com), June 22, 1999.

I don't know you guys. I for ONE, would like to hear "Engineer's" opinion! Say, does Cowle's site have anyone posting as...."Attorney"? Shucks. How about "Sucker"?

-- Will continue (farming@home.com), June 22, 1999.

2.3 There Will Be a Strong Defense of Impracticability. Existing large-scale systems were not made safe from Y2K long ago for good reasons. Many systems resist large-scale modernization ( e.g., IRS, FAA Air Traffic Control, Medicare ) for the same reasons.

Slip? Foregone conclusion?

-- lisa (lisa@work.now), June 22, 1999.

Poole, Decker, Davis, FLINTon, where are youuuuuuuuuuuuuuuuuu??

-- George (jvilches@sminter.com.ar), June 22, 1999.

Let me see. Print a copy for father-in-law, sister-in-law, the DGIs at work, and enclose in e-mail to my entire list.

I wish the IEEE would take out a full page add in the Wall Street Journal. This would never be printed as news. (Sure might cause a stir).

-- Mike Lang (webflier@erols.com), June 22, 1999.

I think that all of the companies that are trying to get this preferential protection against legal liability should plead "no contest" if they ever have to go to court. In essence, they will be saying "We didn't do anything wrong and we promise never to it again."

-- Mr. Adequate (mr@adequate.com), June 23, 1999.

This is MUST READ material for ALL newbies...

Before spin, slant, speculation in one direction or another they should read this first.

Mike =================================================================

-- Michael Taylor (mtdesign3@aol.com), June 23, 1999.

Well, well!

this should be the watershed event of y2k reporting -

need verification??

check para 4.1 - says it all

best to you all

Perry

-- Perry Arnett (pjarnett@pdqnet.net), June 24, 1999.

Does anyone get the distinct impression that as things develop the hole keeps getting deeper and deeper and ....

Father

-- Thomas G. Hale (hale.tg@att.net), June 24, 1999.