Boulder

It was Tuesday afternoon, and I was home. I wandered over to the Ideal Market, the kind of place that has a "customer-of-the-month," to get myself a bagel with lox and cream cheese.

"Have a nice day," the bag person said to me as I walked in the front door.

"Have a nice day," the deli person said, handing me my bagel.

"Have a nice day," said Dennis, the chi-chi butcher, as he vacated his table to go back to selling ground buffalo and turkey bratwurst.

That did it. Enough was enough. I went over to the pay phone and called my realtor. Minutes later the formalities were complete and my house was on the market.

Before I could leave Boulder, however, I had to finish this book. Mind you, this was not out of some sense of duty or an overwhelming desire to clean up loose ends. Half of my advance was payable when I turned in a manuscript suitable for publication, and I needed the money to move.

I did what many Boulder residents do during those rare moments when they have to concentrate, and went to the Trident Cafe. Sitting down, I looked around.

At the next table, a man with unfocused eyes was flipping through a book of star charts, trying to find astrologically similar periods in the past to shed light on the future. In a booth nearby, a guy was dealing out Tarot cards, stopping periodically to stare at his destiny and grumble to himself. The table next to him was spread out with materials for advanced Shambhala training, and next to that three people were engaged in some strange form of group massage.

With so many people looking for inner truth and sharing their feelings, I decided to try and list the good qualities of OSI. After thirty minutes of protocol meditation, however, I looked down at my piece of paper. It contained only one item.

"We have to live with it," my list read.

The goals of the OSI effort are certainly laudable. The concept of open systems is about as hard to argue against as any other lofty ideal. But, saying that being against OSI is to be against open systems assumes there is only one road to truth, beauty, and interoperability.

Quite simply, OSI has not achieved anything close to its goals. Too much complexity, lack of hands-on experience, and far too many fine lunches and dinners had hindered the creation of a lean, mean, finite-state architectural machine.

Just because OSI is not ideal, however, doesn't mean that it can be ignored. OSI has been adopted by many governments as a lowest common denominator of connectivity, taking its place as the logical successor to IBM's RJE and Bisynch protocols.

OSI has become one of those challenges that keep system integrators and consultants employed. OSI is just one of those ugly things you have to deal with when putting together a system, no different than COBOL-driven ISAM files, sendmail configurations, or VTAM routing tables. In fact, OSI has become one of those things that made ideal fodder for students taking MIS classes in business schools:

While OSI has not achieved the goals the committees have set for it, neither was the effort totally wasted. Certainly the careers of hundreds and hundreds of standards potatoes could have been better spent, but there are a few pieces that can be salvaged.

The only way to salvage the work, however, is to get the process out of the hands of those who would build machines in the abstract and back to those who are engaged in the hard, dirty work of building networks. To salvage anything about OSI, the standards have to be known or the work will simply be ignored.

Just because the approach to building networks by committee didn't work doesn't mean that lone wolves can do any better. Rather, a special type of person is needed, one who understands people well enough to mobilize resources and understands the technology well enough to know which resources to mobilize.

In my journey, I met many people who effectively built national networks. Geoff Huston in Australia, Juha Heinänen, in Finland, Jun Murai in Japan, Glenn Kowack from EUnet, and Rick Adams from UUnet are only a few examples of people who successfully built large networks, providing the leadership necessary to turn technology into infrastructure.

While there are many people who succeeded, there are many, many more who spent their time building castles out of air. Efforts like the COSINE project in Europe, for example, kept many people busy making presentations instead of stringing cable.

The ratio of goers to doers in the world of research is just as lopsided. For every Marshall T. Rose, Steve Hardcastle-Kille, or Christian Huitema, there are a hundred people arguing about what to call the TCP/IP protocol suite instead of writing code.

The trick appears to be to provide an environment which allows people to do useful work, and then letting them get on with it. Part of that means providing appropriate resources, but resources alone don't guarantee anything. There are too many multimillion dollar mega-projects that went nowhere to think that throwing money at a problem has any relationship to the final outcome.

In fact, the contrary appears to be the case. There are many projects that started on a shoestring, with a few researchers borrowing a modem and appropriating a phone line. The common denominator in most of these projects was a desire to get work done and a fascination with the technology.

An ad hoc approach to building networks convinced the standards potatoes that the Internet was some kind of academic toy, unsuitable for doing real things. They were wrong and the toy turned out to be the piles of OSI paper.

The Internet is a machine, built by thousands and thousands of engineers to solve real problems. So how can this machine be turned into a truly global infrastructure? How can the spirit of inventiveness that had built the machine in the first place be preserved?

One can think of infrastructure in layers, and it seems that most of the failed efforts can be traced to a tendency to concentrate on one layer to the exclusion of others. As they would say in Boulder (if they thought about it), infrastructure is holistic.

At one layer, you have the real things, the technology that makes networks. Protocols, hardware, and all the technical details that are studied in engineering schools are all part of the real layer.

Technology alone doesn't make a network, though. The next layer is the people layer where technology is applied, deployed, and networks start being used. The leadership of the NSF, DARPA, and the IAB are all functions at the people layer.

Don't think that you can do one layer without the other. NSF provided money and leadership, but the NSFNET also required the solution of many technical problems before it became a reality. Likewise, there are many great technologies that remain research prototypes because nobody takes the time to move them into the field.

One can think of the people layer as the process of governance, but that does not imply government. EUnet and the USENET, for example, are strong evidence that resources can be organized and deployed without the involvement of official bureaucracies.

Eventually, we reach the paper layer, where things are documented. One hopes, of course, that the paper is actually some form of data online. Documentation is the key to allowing the activities in one part to spread to other communities.

Too often, technology remains a black box. By writing down what is happening, others can learn what goes on inside of that black box and improve it. This is the crucial mistake that OSI made when they invented paper, but forgot to show it to anybody.

Paper can mean standards, but it can also mean procedures and policies. Paper has a big impact on how the network is used and who can use it. Standards and the other forms of paper, virtual or real, are the laws and regulations of networks.

These laws have a real effect. Is your routing protocol complex? You've raised the cost of entry. Do You have an acceptable use policy? You've limited your population. Have you invented an anonymous ETP mechanism and an REC series? You've encouraged the spread of the network.

Paper thus reflects something even deeper, the fundamental human values that say what we can do and how. The technology, standards, and networks are all reflections of those values.

Infrastructure, at all levels, reflects how we apply these fundamental human values. Privacy, for example, can be protected or destroyed by a network. There is no inevitable loss of privacy on computer networks, but that is certainly one possible outcome. Likewise, free speech can be encouraged, property can be protected, and we can mold the technology to reflect what we want.

It is the coupling of an awareness of these fundamental values with an understanding of the technology that allows us to build a truly global infrastructure. Technically unsophisticated policy makers make bad laws, just as politically unsophisticated engineers make bad networks.


Educating policy makers and engineers is certainly a nice, long-term goal, but it doesn't provide any concrete steps to be taken today. Putting standards online, though, is a concrete step. The task is technically simple and the benefits were clear.

The Bruno project demonstrated how trivial it is to make information available on computer networks. That this information should, indeed must, be available to all is, to borrow the words of Geoff Huston in Australia, "bloody obvious."

Yet, in pursuing this goal, I ran into a solid wall of resistance. To the people running the process, posting standards leads to the demise of international standards and takes money away from developing countries.

In visiting twenty countries, though, it was obvious to me that the developing countries are the ones most hurt by the policies of the international standards bodies. They are the ones that need most to train engineers, to develop products for export, and to apply cheap, easily-available technology to pressing problems.

Even the developed countries are not helped by policies that restricted participation to a bureaucratic elite. The real networks that I visited were built from the ground up. The most effective networks were built by people with problems to solve. If we want those networks to be interoperable, certainly a goal of the standards process, people building the networks have to be able to get the standards.

The concept of the standards haven is one way around the bureaucracies, but it is not a very productive way to solve the problem. While a few countries probably will post standards for their engineers, nobody had confirmed their intention to do so officially. Indeed, while Korea and India liked the standards haven concept, the idea was caught in the mire of their own bureaucracies. Ultimately, the standards haven concept is a temporary stopgap and a more permanent solution must come directly from the standards cartel. This is a problem crying for global leadership.

Availability of information is one of those fundamental human values that needs to be established as a conscious decision, a fundamental part of the infrastructure. Bruno was a stopgap, and even if a few people working on their own could come up with a new stopgap, what we need is a real solution.


Returning from the coffee shop, it was time to tackle a three-foot-tall pile of mail that had come while I was gone. Having the SnailMAIL to process in a batch let me have a little fun.

As I sorted my mail, I pulled out all the postage-paid cards and put them into a stack, throwing everything else into the recycle bin. I then performed triage on the stack, dividing them up into things I wanted information on (a total of two cards), things I didn't care about, and companies and interest groups I didn't like.

The cards for the bad organizations were left blank and deposited in the nearest post box. Voting with postage-paid cards was a form of economic democracy I learned from my politically-active mother. Over time, individual action can snowball and even the bulkiest bureaucracies will give way.

<<<