 follow- ing simple rules. First, each of the seven layers must perform a clearly defined set of responsibilities that are unique to that layer and guaran- tee the requirement of functional modularity. Second, each layer depends upon the services of the layers above and below to do its own job, as we would expect, given the modular nature of the model. Third, the layers have no idea how the layers around them do what they do; they simply know that they do it. This is called transparency. Finally, there is nothing magical about the number seven. If the industry should decide that we need an eighth layer on the model, or that layer five is redundant (and there are those who think it is), then the model will be changed. The key is functionality. There is an ongoing battle within the ranks of OSI Model pundits, for example, over whether there is actually a requirement for both layers six and seven, because many believe them to be SO simi- lar functionally that one or the other is redundant. Others question whether there is really a need for layer five, the functions of which are considered by many to be superfluous and redundant. To these people I recommend the purchase of a dog. Whether the addition or elimination of a layer ever actually happens is not important. The fact that it can is what matters. It is important to understand that the OSI Model is nothing more than a conceptual way of thinking about data communications. It isn't hardware; it isn't software. It merely simplifies and groups the processes of data transmission SO that they can be easily understood and manipu- lated. Let's look at the OSI Model in a little more detail (see Figure 2-12). I tend to think of it as a seven-drawer chest. In each drawer a collection of standards is stored, and when network implementers set up a network they rummage through each drawer, select the most appropriate stan- dard for their requirements, and set up the network. As we mentioned earlier, the model is a seven-layer construct within which each layer is tightly depen