ay. As far as I know, it is still in place. The principle of the design, like gravity (if I may be SO bold), did not need to be understood to be implemented. The moral here is that we spent weeks on the scheme, which cost the client quite a bit in billable hours. The benefits were not obvious and the time spent was questioned. The benefits were not obvious because they were intangible. Measuring the amount of time that will be saved by never needing to renumber servers is impossible. How much future time and effort will be saved because servers of similar types can be referenced by a single access list entry? What about locations? Countries? We designed the scheme SO that every component of the network could be aggregated into a larger chunk. We designed it SO that entire locations could be moved and only the second octet would change. But all of the time saved was potential. You cannot bank potential time saved. This makes IP scheme design a hard sell to management. But for the employees who work with the network on a daily basis, a great IP scheme can make life substantially easier. Truth #4: Engineers are not always adept at communicating needs to management. Management's view of the network is typically based on a combination of personal experience and input from the engineers. If the engineers are not skilled at communi- cating with their managers, the managers' perceptions are affected accordingly. This really complements all the other issues I've listed. If an engineer knows what needs to be fixed but can't get his manager to understand the need, the manager won't secure the funding for the resolution. once went to a customer's site to investigate client/server problems. The customer was an advertising agency that used very large images, and there were complaints that it was taking too long for the 80 MB graphics files to move from the server to the workstations (this was in the late 1990s, when 80 MB graphics files were unheard of). The problem was a result of having too many devices on a network that was