s names and acronyms to be used instead of neutral identifiers for enti- ties in the model. Since specifying network systems is still document- and not model-driven, we need to emphasize the enormous power of modeling in enhancing creativity and improving communication between people, compared to providing text in docu- ments. Modeling is the creative thinking that you do when trying to find a solution to a problem. Documenting is what you do when you describe your solution. Thus, if you create a model of the system instead of just documenting it, not only do you 1 Introduction to Network System Modeling improve your own thinking, the final model also becomes the documentation (pro- vided that you use a known modeling language and some discipline). Another important side effect of a modeling approach is the possibility to add information to the model that explains which problem a certain feature solves, and why the partic- ular solution has been chosen in favor of already known solutions to the same prob- lem (something you seldom find in traditional system specification and description documents, in particular not in network standards). Every modeling language uses the same basic paradigm for describing the struc- ture of a system, which is that "a system consists of related parts." Considering what we know about the complexity of most systems today, this view seems to be too simplified to be useful (especially since the behavior of systems is not included in the definition). It is, however, of value for something we may call a universal abstraction. This abstraction has been the paradigm for modeling languages that produce things such as semantic diagrams, conceptual models, entity-relation diagram (ER) or entity-relation-attribute diagrams (ERA). Whatever name has been used, these languages all support modeling on the level of universal abstraction: Semantic diagrams were the first to be used, in particular for modeling concepts (e.g., the concept of "religion") and conceptual systems (e.g., the system of numb