worked so hard on achieving. My hope was that you guys would do better than we did, and provide a ubiquitous high quality network (we did high quality, but not ubiquitous). Are you going to get to work and fix it, or continue to screw it up and whine around about the heat in the kitchen? Your choice.

It may just be culture shock going from the role of Internet insider, to Internet outsider. But from the point of view of someone who has always been an outsider, things don't really seem that different than they have in the past. The net goes through cycles of good bandwidth headroom years, and lean bandwidth headroom years. The engineers have always been too busy trying to hold the whole mess together to explain to the Internet populace what was going on. End-to-end network usability has been a persistent problem for the decade+ I've been using the net. The Internet insiders may have been working very hard on management issues. But from the outsider's point of view, the historical net cycle goes something like this. The net's usability slowly declined over the years until reaching a level even network engineers couldn't hand over, then it would suddenly take a leap to a new bandwidth plateau. Yes, network engineers have a long history of finger-pointing and handwaving. But in the past there wasn't anyone who could give a second-opinion. The few end-users who try to measure their perception of the network usability have historically been shouted down. It doesn't seem to matter if there is a high correlation between ping loss rate, and user perception of network performance. All the network engineers know this is a "flawed" testing methodology. This isn't unique to the Internet community. End-users who have the audacity to test their own electrical, telephone, or water service are usually greeted with equal scepticism in by those industries' engineers. Ok, maybe "Internet Management" is an oxymoron. But the lack of centralized management isn't always a bad thing, as long as we can find some invisible hand to guide us. NOC trouble ticket practices, accounting, measurements, and so forth have been on and off the IETF agenda for years. If they were easy problems, I suppsoe they would be solved by now. How about a few positive suggestions which could be implemented in the short-term. The NSFNET Newsletter, Network Status Report list, monthly statistics, and the asnnn@merit.edu and techs contact lists were helpful in generating a consensual reality. Perhaps IDG would be interested in publishing a NANOGWorld, free to "qualified" subscribers chock full with exciting cisco advertisements :-). In the meantime, Sprint's outage list, and UUNET's uunet.status newsgroup, and PSI's and UUNET's World Wide Web pages keep folks informed their network status. I wish more network providers had these services. I wish my own network providers provided these services. Statistics seems to be the toughest issue. But also an important one for communicating the state the net with Internet outsiders. AT&T always tells the world how many phone calls were made through its network on Mother's day, or after an earthquake. There are two reasons for this. One is to say how important AT&T is. The second, more important reason, is to help generate a state of mind in their customers why the network may have flaked out on those days. Yes, statistics can lie. But even hard lies are better than hand-waving. And finally, a plea for a common method of notifying a network provider's NOC of a potential problem. If you never hear about the problem, how can you fix it. I understand everyone gives their own customer calls priority. But sometimes even my provider's provider's provider can't figure out how to contact different noc's. noc@somewhere, trouble@whatever, engineer@wherever, action@whoever, etc, etc, etc. My rolodex is crumbling under the weight of keeping track of who works where this week. If folks want to write a Best Common Practice, this is one area that could really use it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation